高可用复杂度模型
计算高可用 - 任务分配
【任务分配】
将任务分配给多个服务器执行。
【复杂度分析】
1. 增加“任务分配器”节点，可以是独立的服务器，也可以是 SDK。
2. 任务分配器需要管理所有的服务器，可以通过配置文件，也可以通过配置服务器（例如 ZooKeeper）。
3. 任务分配器需要根据不同的需求采用不同的算法分配。
4. 任务分配器需要监控业务服务器的状态，在故障时进行切换。
计算高可用任务分配架构设计关键点
计算高可用任务分配案例
计算高可用 - 任务分解
【任务分解】
将服务器拆分为不同角色，不同服务器处理不同的业务。
【复杂度分析】
1. 增加“任务分解器”节点，可以是独立的服务器，也可以是SDK。
2. 任务分解器需要管理所有的服务器，可以通过配置文件，也可以通过配置服务器（例如 ZooKeeper）。
3. 需要设计任务拆分的方式，任务分解器需要记录“任务”和“服务器”的映射关系。
4. 任务分配器需要根据不同的需求采用不同的算法分配。
5. 任务分解器需要监控业务服务器的状态，在故障时进行切换。
存储高可用复杂度模型
存储高可用 - 数据复制格式
存储高可用 - 数据复制方式1
存储高可用 - 数据复制方式2
高可用存储复制案例
Redis
复制格式：命令（AOF） + 文件（RDB）
复制方式：异步 + wait（指定半同步）
MySQL
复制格式：命令（statement） + 数据（Row）
复制方式：异步 + 半同步
存储高可用状态决策 - 独裁式
存储高可用状态决策 - 协商式
【优缺点】
1. 架构实现简单，决策逻辑简单，一般是心跳机制；
2. 如果是链路问题，会导致双主，可以用双通道来缓解；
3. 数据一致性弱。
【应用场景】
内部系统、网络设备（用串口相连）。
存储高可用状态决策 - 民主式/选举式
【优缺点】
1. 决策过程复杂，决策逻辑复杂，一般用标准算法进行选举，例如 Raft、ZAB、Paxos；
2. 可用性最高，数据一致性最强；
3. 可能出现“脑裂”问题，可以采用 quorum 来控制。
【应用场景】
对数据一致性要求很高的场景，例如余额、库存。
存储高可用状态决策 - 独裁式案例
Redis：使用 sentinel 集群来解决“决策者”单点问题，sentinel 又是通过 Raft 算法进行选举的。
Hadoop：NameNode 是集群决策者，使用 ZooKeeper 集群来解决NameNode 单点问题。
存储高可用状态决策 - 民主式案例1
ZooKeeper：基于 ZAB 算法选举
MongoDB：3.2.0 以前基于 bully 算法，3.2.0 开始基于 Raft 算法。
思维导图：
