从0开始学架构-高可用架构模式_高可用架构学习-CSDN博客

本文链接：https://blog.csdn.net/hixiaoxiaoniao/article/details/86744927

理论

理论

CAP

一致性 Consistency
可用性
分区容忍性Partition Tolerance

分布式系统必须要有P，所以只能选择CP，AP

CP Consistency/Partition Tolerance
AP Availability/Partition Tolerance

CAP细节

CAP关注的粒度是数据，而不是整个系统
CAP是忽略网络延迟
正常运行情况下，不存在CP和AP的选择，可以同时满足CA
放弃并不等于什么都不做，需要为分区恢复后做准备

ACID

Atomicity 原子性
Consistency 一致性
Isolation 隔离性
Durability 持久性

BASE

基本可用 Basically Available
软状态 Soft State
最终一致性 Eventual Consistency

BASE的细节

CAP理论是忽略延时的，而实际应用中延时是无法避免的
AP方案中牺牲一致性只是指分区期间，而不是永远放弃一致性

FMEA

FMEA failure mode and effects analysis 故障模式与影响分析

FMEA是一种在各行各业都有广泛应用的可用性分析方法，通过对系统范围内潜在的故障模式加以分析，并按照严重程序进行分类，以确定失效对于系统的最终影响
FMEA分析方法就是一个FMEA分析表
分析中的功能点，是从用户的角度来看的，而不是从系统各个模块功能点划分来看的
分析中故障模式的描述要尽量精确，所使用量化描述，避免使用泛化的描述
分析中的严重程序指站在业务的角度，故障的影响程序一般分为致命/高/中/低/无
分析中不同的故障原因发生概率，检测手段和处理措施可能不同
分析中的风险程度就是综合严重程度和故障概率来一起判断某个故障的最终等级
分析中不一定所有的问题都要解决，采取规避措施也可以

以用户登录注册为例，单个Server，单个Memcached服务器，单个MySql服务器

存储高可用

需要从以下几个方面思考
1.数据如何复制
2.各个节点的职责是什么
3.如何应对复制延迟
4.如何应对复制中断

主备方式

主备复制

备机仅仅只为备份没有提供读写操作，故障后需要人工干预

主从复制
比主备效率高一些，故障后也需要人工干预

主备倒换与主从倒换
要实现此方案需要如下几点
1.主备之间的状态判断
状态传递的渠道
状态监测的内容
2.倒换决策
倒换时机
倒换策略
自动程度
3.数据冲突解决

常见架构
互联式
主备/主从机器之间可以共享一个虚拟IP
中介式
决策比互联式更简单，MongoDB就是这种模式，ZooKeeper
模拟式
从节点模拟成客户端去读取数据，但无法检测出状态

主主复制
两台都是主机，不存倒换
客户端无须区分不同角色的主机，随便讲读写操作发送给哪台主机都可以
很多书籍不能双向复制
用户1在A注册id=100，用户2在B注册id=100，这就不能复制
库存不能双向复制

数据集群

数据集中集群
一主多从模式
主机如何将数据复制给备份/从机器
备份机器如何检测主机状态
主机故障后，如何决定新的主机

数据分散集群
复杂点在于如何将数据分配到不同的服务器上，需要考虑如下
均衡性，每台机器数据相差不大
容错性，当部分数据故障时，需将故障服务器的数据分区分配给其他服务器
可伸缩性，需要考虑到扩容
Hadoop 和 ElasticSearch

分布式事务算法

2PC

协调者向所有参与者发送Query to commit消息，询问是否可以执行提交事务并等待各参与者响应
参与者执行询问发起为止的所有事务操作，并将undo和redo信息写入日志，并返回成功/失败给协调者
第二阶段，协调者向所有参与者发送commit，等待他们的ACK，若有一个参与者出错，协调者发送rollback

2PC的缺点

同步阻塞，整个过程中协调者和参与者互相等待对方的响应消息，难以支撑高并发场景
状态不一致，如果发生分区，某个参与者会一直收不到commit，而他参与者都commit了，等超时后协调者再发送commit，但此参与者可能一直收不到导致状态不一致
单点故障，如果协调者故障，参与者会一直等待下去

3PC

第一阶段，协调者向参与者发送canCommit消息
参与者收到canCommit后，判断自己是否可以提交并返回yes/no
如果协调者收到任何一个no或者参与者超时则终止事务，同时会通知参与者终止事务
第二阶段，协调者发送preCommit消息给所有参与者告诉参与者准备提交
参与者收到哦preCommit消息后，执行事务操作，将undo和redo消息记录到事务日志中
第三阶段，协调者再接收到所有ACK消息后会发送doCommit，告诉参与者正式提交，否则回滚
参与者收到doCommit消息后提交事务，并返回成功
如果参与者收到一个preCommit返回了ACK，但等待doCommit小时超时(协调者崩溃)，参与者在超时后会继续提交事务

三阶段提交算法虽然避免了两阶段提交算法的协调者单点故障导致系统阻塞的问题，但同样存在数据不一致问题

分布式一致性算法
分布式事务算法的主要目的是为了保证分散在多个节点上的数据统一提交或回滚，以满足ACID的要求，而分布式
一致性算法的主要模板第是为了保证同一份数据在多个节点上的一致性，以满足CAP中的CP要求
复制状态机是实现分布式一致性的常用技术，主要角色如下

副本，多个分布式服务器组成一个集群，每个服务器都包含完整状态机的一个副本
状态机，状态机接受输入，然后执行操作，将状态改变为下一个状态
算法，使用算法来协调各个副本的处理逻辑，使得副本的状态机保持一致

Paxos算法
Raft，不完整版的Paxos
ZAB，和Raft类似，强化了Leader作用，也是不完整版

数据分区
将数据按照一定的规则进行分区，不同分区分布在不同的地理位置上，每个分区存储一部分数据，通过这种方式
来规避地理级别的故障所造成的巨大影响

数据量的大小直接决定了分区的规则复杂度，数据量越大分区规则越复杂，考虑的情况也越多
分区规则

洲际分区，可以不互通或仅做备份
国家分区，面向不同国家提供不同语言法律业务服务，仅做备份
城市分区，可以满足业务多活需求

复制规则
分区后的数据同样也需要备份

集中式，所有的分区都将数据备份到备份中心
互备式，每个分区备份另外一个分区的数据，扩展麻烦
独立式，每个分区自己又独立的备份中心，成本高

计算高可用

哪些服务器可以执行任务
所有的服务器
只有主服务器才可以
任务如何重新执行
对于已分配的任务及时执行失败也不做处理
设计一个任务管理器来管理需要执行的计算任务

主备
包括冷备和温备

冷备，是配置和程序都准备好了，但业务还没启动
温备，是业务已启动了但不对外提供服务，温备的切换时间更端

主从

主从架构从机器也可以执行任务
主从架构需要将任务分类，任务分配器会复杂一些

对称集群

类似存储高可用中的集群，需要有负载均衡分配方式
负载均衡集群设计关键，任务分配器需要检测服务器状态，任务分配器需要选取分配策略

非对称集群

集群通过某种方式来区分不同服务器的角色
任务分配器将不同任务发送给不同服务器
当指定类型的服务器故障时需要重新分配角色

和对称集群相比复杂度体现在

任务分配策略更复杂
角色分配策略实现比较复杂

以ZooKeeper为列

任务分配器，ZooKeeper中不存在独立的任务分配器节点，每个Server都是任务分配器，Follower接收到请求后会进行判断，如果是写请求就转发给Leader，否则自己处理
角色指定，ZooKeeper通过ZAB协议来选举Leader，当Leader故障后，所有的Follwer节点会暂停读写操作，开始进行选举，直到新的Leader选举出来后才继续对Client提供服务

业务高可用

异地多活标准

整除情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的业务服务
某地系统异常情况下，用户访问到其他地方整除的业务系统，也能够得到正确的业务服务

异地多备是不提供服务，需要人工干预和操作才能让备变成活
异地多活的缺点
1.系统复杂度会发生质的变化，需要设计服装的异地多活架构
2.成本会上升，需要在一个或多个机房搭建独立的一套业务系统

如果业务规模很大，能做异地多活尽量实现
1.能够在异常的场景下提供更好的体验
2.业务规模很大也会伴随着衍生收入

异地多活架构

同城异区
关键在于搭建高速网络将两个机房连接起来，达到近似一个本地机房的效果
架构上可以将两个机房当做本地机房设计无须额外考虑
跨城异地
延迟问题给设计带来复杂度
数据在段时间不一致的情况下，还能正常提供业务
银行类的业务就无法做跨城异地多活，只能同城异地架构
对数据一致性要求不那么高的场景可以做异地多活
跨国异地
为不同地区用户提供服务
只读类业务做多活

跨城异地多活是最复杂的，设计技巧
1.保证核心业务异地多活
手机注册这种就无法做双活，A注册后宕机，B不能再注册
也不能一个手机注册一个改成多个，改核心业务代价太大
弄一个全局唯一递增的ID，这种方案可以但成本很高
注册，登陆，用户信息全做高可用几乎不可能，优先实现核心业务异地多活即可

2.核心数据最终一致性
本质上是通过异地的数据冗余保证极端情况下业务能正常运行
异地多活理论上不可能很快，这是物理定律决定的
尽量减少数据同步，只同步核心业务相关的数据
保证最终一致性，不保证实时一致性

3.采用多种手段同步数据
开源系统本身的同步方式可能满足不了异地多活需求
消息队列方式
二次读取方式
存储系统同步方式，对密码这种修改频率低的
回源读取方式
重新生成数据方式

4.只保证绝大部分用户异地多活
对金融系统，若用户在北京注册，只能从北京机房转账
可以发起转账申请，上海机房异步请求等北京机房恢复后再执行
补偿方式：挂公告，事务对用户补偿，补充体验

异地多活的设计理念总结：
采用多种手段，保证绝大部分用户的核心业务异地多活

异地多活设计步骤

1.业务分级
访问量大的业务，核心业务，产生大量收入的业务
2.数据分类
数据量，唯一性，实时性，可丢失性，可恢复性

3.数据同步
存储系统自身的同步，消息队列同步，重复生成

4.异常处理
多通道同步，消息队列+存储系统自身，kakfa和mysql用不同网络连接(电信+联通)，数据是可以重复覆盖的
同步和访问相结合，通过系统接口访问数据(走公网)，多通道同步(内网)
日志记录，故障恢复后对数据进行恢复，包括服务器保存，本地系统保存，异地保存
用户补偿，人工补偿0.01%用户的损失

接口级故障应对方案

相比机房故障，接口故障概率更高
优先保证核心业务，优先保证绝大部分用户
内部原因，程序bug导致慢查询
外部原因，黑客攻击，促销等

1.降级
核心思想是丢车保帅，优先保证核心业务
系统后门URL降级
独立系统降级
2.熔断
降级目的是应对系统自身故障
熔断目的是应对依赖的外部系统故障
若A服务的X功能依赖B，如果B很慢会影响A服务，熔断即不再请求B接口
关键阈值，1分钟内30%请求时间超过阈值
3.限流
从用户访问压力的角度来考虑应对故障
基于请求限流，如超过1分钟只允许1W人进入
基于资源限流
限流不好确定阈值，需要慢慢优化
4.排队
增加排队模块
调度模块，从队列中取出请求并向服务模块发送请求，可动态调节排队系统拉去请求的速度