目录
理论
CAP
FMEA
存储高可用
主备方式
数据集群
分布式事务算法
计算高可用
业务高可用
异地多活标准
异地多活架构
异地多活设计步骤
接口级故障应对方案
分布式系统必须要有P,所以只能选择CP,AP
CAP细节
ACID
BASE
BASE的细节
FMEA failure mode and effects analysis 故障模式与影响分析
以用户登录注册为例,单个Server,单个Memcached服务器,单个MySql服务器
需要从以下几个方面思考
1.数据如何复制
2.各个节点的职责是什么
3.如何应对复制延迟
4.如何应对复制中断
主备复制
备机仅仅只为备份没有提供读写操作,故障后需要人工干预
主从复制
比主备效率高一些,故障后也需要人工干预
主备倒换与主从倒换
要实现此方案需要如下几点
1.主备之间的状态判断
状态传递的渠道
状态监测的内容
2.倒换决策
倒换时机
倒换策略
自动程度
3.数据冲突解决
常见架构
互联式
主备/主从机器之间可以共享一个虚拟IP
中介式
决策比互联式更简单,MongoDB就是这种模式,ZooKeeper
模拟式
从节点模拟成客户端去读取数据,但无法检测出状态
主主复制
两台都是主机,不存倒换
客户端无须区分不同角色的主机,随便讲读写操作发送给哪台主机都可以
很多书籍不能双向复制
用户1在A注册id=100,用户2在B注册id=100,这就不能复制
库存不能双向复制
数据集中集群
一主多从模式
主机如何将数据复制给备份/从机器
备份机器如何检测主机状态
主机故障后,如何决定新的主机
数据分散集群
复杂点在于如何将数据分配到不同的服务器上,需要考虑如下
均衡性,每台机器数据相差不大
容错性,当部分数据故障时,需将故障服务器的数据分区分配给其他服务器
可伸缩性,需要考虑到扩容
Hadoop 和 ElasticSearch
2PC
2PC的缺点
3PC
三阶段提交算法虽然避免了两阶段提交算法的协调者单点故障导致系统阻塞的问题,但同样存在数据不一致问题
分布式一致性算法
分布式事务算法的主要目的是为了保证分散在多个节点上的数据统一提交或回滚,以满足ACID的要求,而分布式
一致性算法的主要模板第是为了保证同一份数据在多个节点上的一致性,以满足CAP中的CP要求
复制状态机是实现分布式一致性的常用技术,主要角色如下
数据分区
将数据按照一定的规则进行分区,不同分区分布在不同的地理位置上,每个分区存储一部分数据,通过这种方式
来规避地理级别的故障所造成的巨大影响
数据量的大小直接决定了分区的规则复杂度,数据量越大分区规则越复杂,考虑的情况也越多
分区规则
复制规则
分区后的数据同样也需要备份
哪些服务器可以执行任务
所有的服务器
只有主服务器才可以
任务如何重新执行
对于已分配的任务及时执行失败也不做处理
设计一个任务管理器来管理需要执行的计算任务
主备
包括冷备和温备
主从
对称集群
非对称集群
和对称集群相比复杂度体现在
以ZooKeeper为列
异地多备是不提供服务,需要人工干预和操作才能让备变成活
异地多活的缺点
1.系统复杂度会发生质的变化,需要设计服装的异地多活架构
2.成本会上升,需要在一个或多个机房搭建独立的一套业务系统
如果业务规模很大,能做异地多活尽量实现
1.能够在异常的场景下提供更好的体验
2.业务规模很大也会伴随着衍生收入
同城异区
关键在于搭建高速网络将两个机房连接起来,达到近似一个本地机房的效果
架构上可以将两个机房当做本地机房设计无须额外考虑
跨城异地
延迟问题给设计带来复杂度
数据在段时间不一致的情况下,还能正常提供业务
银行类的业务就无法做跨城异地多活,只能同城异地架构
对数据一致性要求不那么高的场景可以做异地多活
跨国异地
为不同地区用户提供服务
只读类业务做多活
跨城异地多活是最复杂的,设计技巧
1.保证核心业务异地多活
手机注册这种就无法做双活,A注册后宕机,B不能再注册
也不能一个手机注册一个改成多个,改核心业务代价太大
弄一个全局唯一递增的ID,这种方案可以但成本很高
注册,登陆,用户信息全做高可用几乎不可能,优先实现核心业务异地多活即可
2.核心数据最终一致性
本质上是通过异地的数据冗余保证极端情况下业务能正常运行
异地多活理论上不可能很快,这是物理定律决定的
尽量减少数据同步,只同步核心业务相关的数据
保证最终一致性,不保证实时一致性
3.采用多种手段同步数据
开源系统本身的同步方式可能满足不了异地多活需求
消息队列方式
二次读取方式
存储系统同步方式,对密码这种修改频率低的
回源读取方式
重新生成数据方式
4.只保证绝大部分用户异地多活
对金融系统,若用户在北京注册,只能从北京机房转账
可以发起转账申请,上海机房异步请求等北京机房恢复后再执行
补偿方式:挂公告,事务对用户补偿,补充体验
异地多活的设计理念总结:
采用多种手段,保证绝大部分用户的核心业务异地多活
1.业务分级
访问量大的业务,核心业务,产生大量收入的业务
2.数据分类
数据量,唯一性,实时性,可丢失性,可恢复性
4.异常处理
多通道同步,消息队列+存储系统自身,kakfa和mysql用不同网络连接(电信+联通),数据是可以重复覆盖的
同步和访问相结合,通过系统接口访问数据(走公网),多通道同步(内网)
日志记录,故障恢复后对数据进行恢复,包括服务器保存,本地系统保存,异地保存
用户补偿,人工补偿0.01%用户的损失
相比机房故障,接口故障概率更高
优先保证核心业务,优先保证绝大部分用户
内部原因,程序bug导致慢查询
外部原因,黑客攻击,促销等
1.降级
核心思想是丢车保帅,优先保证核心业务
系统后门URL降级
独立系统降级
2.熔断
降级目的是应对系统自身故障
熔断目的是应对依赖的外部系统故障
若A服务的X功能依赖B,如果B很慢会影响A服务,熔断即不再请求B接口
关键阈值,1分钟内30%请求时间超过阈值
3.限流
从用户访问压力的角度来考虑应对故障
基于请求限流,如超过1分钟只允许1W人进入
基于资源限流
限流不好确定阈值,需要慢慢优化
4.排队
增加排队模块
调度模块,从队列中取出请求并向服务模块发送请求,可动态调节排队系统拉去请求的速度