高可用复杂度模型

计算高可用

任务分配

将任务分配给多个服务器执行

复杂度分析

1. 增加“任务分配器”节点，可以是独立的服务器，也可以是SDK
2. 任务分配器需要管理所有的服务器，可以通过配置文件，也可以通过配置服务器（例如Zookeeper）
3. 任务分配器需要根据不同的需求采用不同的算法分配
4. 任务分配器需要监控业务服务器的状态，在故障时进行切换

任务分配架构设计关键点

案例

任务分解

将服务拆分为不同角色，不同服务器处理不同的业务

复杂度分析

1. 增加“任务分解器”节点，可以是独立的服务器，也可以是SDK
2. 任务分解器需要管理所有的服务器，可以通过配置文件，也可以通过配置服务器（例如Zookeeper）
3. 需要设计任务拆分的方式，任务分解器需要记录“任务”和“服务器”的映射关系
4. 任务分配器需要根据不同的需求采用不同的算法分配
5. 任务分解器需要监控业务服务器的状态，在故障时进行切换

任务分解架构设计关键点

案例-微信服务拆分

架构模式

1. 按照业务逻辑划分服务器集群
2. 独立的接入服务器

存储高可用

复杂度模型

数据复制

复制格式

复制命令

优缺点

1. 实现简单，复制数据量小
2. 数据可能不一致（SQL函数）

适用场景

增量复制

复制数据

优缺点

1. 实现简单
2. 保证数据一致
3. 复制流量可能会很大

适用场景

增量复制

复制文件

优缺点

1. 实现复杂，复制的时候数据在变
2. 保证数据一致
3. 复制流量可能会很大

适用场景

全量复制

复制方式

同步复制

优缺点

1. 最强一致性，故障容忍度低
2. 写入性能低

适应场景

主备/主从架构

异步复制

优缺点

1. 写入性能高，故障容忍度高
2. 容易出现数据不一致

适应场景

数据存储集群

半同步复制

优缺点

同步复制和异步复制的折中方案

适应场景

数据存储集群

多数复制

优缺点

1. 数据强一致性，最强可用性，故障容忍度高
2. 写入性能不高，实现复杂

适应场景

分布式一致性、分布式协同

案例

Redis

复制格式：命令（AOF）+文件（RDB）

复制方式：异步+wait（指定半同步）

MySQL

复制格式：命令（statement）+数据（Row）

复制方式：异步+半同步

状态决策

方式

独裁式

优缺点

1. 决策逻辑简单
2. 决策者要做到高可用，整体架构复杂，常用Zookeeper、Raft、Keepalived
3. 数据一致性强度中等

应用场景

绝大部分业务都可以应用

协商式

优缺点

1. 架构实现简单，决策逻辑简单，一般是心跳机制
2. 如果是链路问题，会导致双主，可以用双通道来缓解
3. 数据一致性弱

应用场景

内部系统

民主式/选举式

优缺点

1. 决策过程复杂，决策逻辑复杂，一般用标准算法进行选举，例如Raft、ZAB、Paxos
2. 可用性最高，数据一致性最强
3. 可能出现“脑裂”问题，可以采用quorum来控制

应用场景

对数据一致性要求很高的场景，例如余额、库存

案例

独裁式

Redis

使用Sentinel集群来解决“决策者”单点问题，sentinel又是通过Raft算法进行选举的

Hadoop

NameNode是集群决策者，使用Zookeeper集群来解决NameNode单点问题

民主式

Zookeeper

基于ZAB算法选举

MongoDB

3.2.0以前基于bully算法，3.2.0开始基于Raft算法