高可用

程序无涯海2 天前
面试·系统设计·高可用·秒杀系统·抢红包
面试篇-系统设计题总结抢红包系统其实也是秒杀类中的一个场景,抢红包的特点在于无法超售,下单中的超卖、少卖问题是可以允许的。但是对于红包,一旦用户抢到的钱比发出去的钱更多,那就是大问题了。
Alex Gram3 天前
系统架构·keepalived·高可用
Windows怎么实现虚拟IP在做高可用架构时,往往需要用到虚拟IP,在linux上面有keepalived来实现虚拟ip的设置。在windows上面该怎么弄,keepalived好像也没有windows版本,我推荐一款浮动IP软件PanguVip,它可以实现windows上面虚拟ip的漂移。设置完虚拟IP后,可以达到这样的效果,即客户端使用虚拟IP访问服务,当主节点宕机后,虚拟IP漂移到备胎服务器上,客户端使用虚拟IP访问服务依然可行,对于客户端来说是无感知的。当然前提是主节点和备胎节点都部署了相同的服务,如果是数据库服务,那还得做
coffee_babe4 天前
java·服务器·数据库·mysql·高可用
MySQL之高可用性(四)冗余是很好的技术,但实际上只有在遇到故障需要恢复时才会用到。(见鬼,这可以用备份来实现)。冗余一点儿也不会增加可用性或减少宕机。在故障转移的过程中,高可用性是建立在冗余的基础上。当有一个组件失效,但存在冗余时,可以停止使用发生故障的组件,而使用冗余备件。冗余和故障转移结合可以帮助更快地恢复,如你所知,MTTR(平均恢复时间)的减少将降低宕机时间并改善可用性。在继续这个话题之前,我们先来定义一些术语。我们统一使用"故障转移(failover)",有些人使用"回退(fallback)“来表达同一意思。有时候也
coffee_babe5 天前
java·服务器·数据库·mysql·高可用
MySQL之高可用性(二)找到并消除系统中的可能失效的单点,并结合切换到备用组件的机制,这是一种通过减少恢复时间(MTTR)来改善可用性的方法。如果你够聪明,有时候甚至能将实际的恢复时间降低至0,但总的来说这很困难。(即使一些非常引人注目的技术,例如昂贵的负载均衡器,在发现问题并进行反馈时也会导致一定的延迟)。思考并梳理整个应用,尝试去定位任何可能失效的单点。是一个硬盘驱动器,一台服务器,一台交换或路由器,还是某个机架的电源?所有数据都在一个数据中心,或者冗余数据中心是由同一个公司提供的吗?系统中任何不冗余的部分都是一个可能失效的
lldhsds16 天前
kubernetes·高可用
Ubuntu24使用kubeadm部署高可用K8S集群使用kubeadm部署一个k8s集群,3个master+1个worker节点。最终目标部署一个HA Kubernetes 集群,使用堆叠(stacked)控制平面节点,其中 etcd 节点与控制平面节点共存。
年薪丰厚20 天前
运维·nginx·keepalived·高可用
nginx+keepalived高可用搭建的详细步骤现在有2台机器,10.5.100.36 和 10.5.100.37,分别在这2台机器上面部署nginx和keepalived,然后利用keepalived对nginx做高可用。
小哈里22 天前
linux·服务器·网络·高可用·后端开发
【后端开发】服务开发场景之高可用(冗余设计,服务限流,降级熔断,超时重试,性能测试)【后端开发】服务开发场景之高可用(冗余设计,服务限流,降级熔断,超时重试,性能测试)高可用描述的是一个系统在大部分时间都是可用的,可以为我们提供服务的。高可用代表系统即使在发生硬件故障或者系统升级的时候,服务仍然是可用的。
Hello-Brand25 天前
缓存·性能优化·高可用·熔断限流·微服务化·单元化
千万级流量冲击下,如何保证极致性能随着互联网的快速发展,网络应用的流量规模不断攀升,特别是在电商大促、明星直播、重大赛事、头条热搜等热点事件中,秒级100w请求成为了常态。在这样的流量冲击下,如何确保系统稳定、高效地处理每一个请求,为用户提供极致的体验,成为了技术团队面临的重要挑战。本文将深入探讨在超高流量下如何保证系统的极致性能。
李庆政3701 个月前
运维·nginx·负载均衡·keepalived·高可用
ubuntu22 搭建nginx高可用集群(VIP(keepalived) + 负载均衡)#ps: 如果要使用tcp流转发:需用二进制包安装 make编译时加入stream流的参数。 推荐直接安装openresty【默认支持stream等nginx模块,还附带了很多常用的lua库】
Hello-Brand3 个月前
缓存·高可用·稳定性·哨兵·redis 6.0·redis sentinel
高可用之战:Redis Sentinal(哨兵模式)★ Redis24篇集合在我们的《Redis高可用之战:主从架构》篇章中,介绍了Redis的主从架构模式,可以有效的提升Redis服务的可用性,减少甚至避免Redis服务发生完全宕机的可能。 它主要包含如下能力: 1. 故障隔离和恢复:无论主节点或者从节点宕机,其他节点依然可以保证服务的正常运行,并可以手动或自动切换主从。
Hello-Brand3 个月前
微服务·架构·高可用·架构与思维·可靠性·系统架构设计
架构与思维:一定需要微服务么?微服务架构的发展伴随着互联网行业的飞速增长和技术的日新月异。起初,企业为了提升应用的灵活性和可维护性,开始尝试将单体应用拆分为多个服务,这便是面向服务的架构(SOA)的兴起。然而,此时的拆分粒度仍然相对较大,并没有完全实现服务的细粒度划分。
我要出家当道士3 个月前
nginx·keepalived·高可用·虚拟ip
KeepAlived使用介绍目录1、Introduce2、基本使用(1)安装(2)配置文件(3)使用教程keepalived是一个用于实现高可用性和负载均衡的开源软件。它提供了一种轻量级的方式来管理多个服务器,并确保它们在故障发生时继续正常工作。keepalived 通常用于构建高可用性的网络服务,如Web服务器、数据库服务器等。
Hello-Brand4 个月前
负载均衡·高可用·roundrobin
常用负载均衡详解(图文总结)在互联网场景下,负载均衡(Load Balance)是分布式系统架构设计中必须考虑的一个环节,它通常是指将负载流量(工作任务、访问请求)平衡、分摊到多个操作单元(服务器、组件)上去执行的过程。 目的在于提供负载配比,解决性能、单点故障(高可用)和扩展性(水平伸缩)等问题。 以上图为例,随着互联网的兴盛,类似淘宝、京东等网站的访问量逐年提升。原先的单台服务或者单集群模式已经远不能满足需求了,这时候就需要横向扩展多台服务或者多个集群来分摊压力,达到提升系统吞吐的能力,这就是著名的分治理论。 但服务器增加了,他
田超凡4 个月前
docker·高可用
高可用篇_A Docker容器化技术_I Docker基本概念原创作者:田超凡(程序员田宝宝)版权所有,引用请注明原作者,严禁复制转载1.Docker 是一个开源的应用容器引擎,基于 Go 语言 并遵从 Apache2.0 协议开源。
Hello-Brand4 个月前
redis·缓存·高可用·稳定性·rdb·aof指令
Redis稳定性之战:AOF日志支撑数据持久化★ Redis24篇集合AOF(Append Only File)持久化:以独立日志的方式存储了 Redis 服务器的顺序指令序列,并只记录对内存进行修改的指令。 当Redis服务发生雪崩等故障时,可以重启服务并重新执行AOF文件中的指令达到恢复数据的目的。也就是说,通过重放(replay),来重新建立 Redis 当前实例的内存数据结构。这种模式有没有很熟悉,可以联想到MySQL主从同步时的relay log。 相对于咱们上一篇介绍的《RDB内存快照提供持久化能力》定点快照的做法,AOF的主要作用是解决
华为云开发者联盟4 个月前
集群·高可用·华为云开发者联盟
教你如何用Keepalived和HAproxy配置高可用 Kubernetes 集群本文分享自华为云社区《使用 Keepalived 和 HAproxy 创建高可用 Kubernetes 集群》,作者:江晚正愁余。
Hello-Brand5 个月前
微服务·去中心化·高性能·高可用·系统架构设计·依赖降级
架构设计:千万级流量下的数据强依赖降级互联网场景下,我们经常会面临一个产品流量从初创时期的小流量到全盛大流量的过程。 这时候,原本的架构设计就显得很不合理,变成你追求服务稳定性阻碍。 然而这一切并不一定是你的架构能力的问题,而是在小流量场景下,不能过高的去评估容量和架构冗余性,避免造成不必要的资源和维护人力的浪费。 能做的是为以后的架构演进提供可扩展性准备,让原本强依赖数据存储层的风险可以实现逐层降级。
Firechou6 个月前
mongodb·docker·集群·高性能·高可用·复制集
MongoDB搭建复制集集群(Docker版)关于复制集:关于硬件:关于软件:一主两从架构图:(1)准备配置文件 复制集的每个 mongod 进程应该位于不同的服务器。我们现在在一台机器上运行 3 个进程,因此要为它们各自配置:
p1sto6 个月前
分布式·spring cloud·微服务·云原生·架构·实战项目·高可用
微服务实战项目_天机学堂01_初识项目Q:天机学堂是什么?A:天机学堂是一个基于微服务架构的生产级在线教育项目主要有两个端(项目已上线,可以点击查看):
Hello-Brand6 个月前
微服务·架构·去中心化·高可用·架构与思维·解耦·系统架构设计·弱依赖
高可用架构,去中心化有多重要?★ 微服务系列18篇在互联网高可用架构设计中,应该避免将所有的控制权都集中到一个中心服务,即便这个中心服务是多副本模式。 对某个中心服务(组件)的过渡强依赖,那等同于把命脉掌握在依赖方手里,依赖方的任何问题都可能成为你不稳定的因素。 而弱化强依赖,实现可降级交互,是一种设计理念和架构模式,目的是将系统的控制权分散到各个节点,避免出现单点故障或中心化控制的问题。 这一点,我们称之为『去中心化』。