1. 高可用复杂度模型
- 核心思想:遵循“冗余法则”,通过集群化实现高可用,避免单点故障。
a.单机高可用不存在:单机无法冗余,高可用必须依赖集群。
b.复杂度本质:冗余带来的复杂性,包括状态同步、故障切换、数据一致性等。
2. 计算高可用
2.1 任务分配
- 核心设计:通过任务分配器(独立服务器或SDK)将任务分发到多个服务器。
- 复杂度分析:
a.任务分配器需管理服务器列表(配置文件或ZooKeeper)。
b.需动态监控服务器状态,故障时快速切换。
c.算法选择(轮询、哈希、权重等)影响负载均衡。
- 关键点:高性能架构关注正常处理,高可用架构关注异常容错。
2.2 任务分解
- 核心设计:按业务逻辑拆分服务器角色(如接入层、逻辑层、存储层)。
- 复杂度分析:
a.任务分解器需记录任务与服务器的映射关系。
b.局部故障隔离,避免业务互相影响。
- 案例:微信服务拆分(独立接入服务器+业务集群)。
3. 存储高可用
3.1 数据复制格式
- 命令复制(如Redis AOF):
a.优点:数据量小,实现简单。
b.缺点:可能不一致(依赖SQL函数)。
c.场景:增量复制。
- 文件复制(如MySQL Row格式):
- 优点:数据一致性强。
- 缺点:流量大。
- 场景:全量复制。
- 混合复制(如Redis RDB+AOF):
- 折衷方案,平衡一致性与性能。
3.2 数据复制方式
- 同步复制:
a.强一致性,但写入性能低(需所有节点确认)。
b.场景:主备架构。
- 异步复制:
a. 高性能,容忍节点故障,但可能数据丢失。
b.场景:数据存储集群。
- 半同步复制(如MySQL半同步):
a. 折衷方案,部分节点确认即可。
- 多数复制(如ZooKeeper):
a.强一致性+高可用性,但实现复杂。
b.场景:分布式一致性系统(OceanBase)。
3.3 状态决策模式
- 独裁式(如Redis Sentinel):
a.决策者单点需高可用(依赖ZooKeeper/Raft)。
b.一致性中等,适用于通用业务。
- 协商式(如心跳检测):
a.简单但易双主(需双通道缓解)。
b.一致性弱,适合内部系统。
- 民主式(如Raft/ZAB算法):
a.高一致性+高可用,但可能脑裂(需Quorum控制)。
b.场景:余额、库存等高一致性需求。
4. 案例与模式
- Redis:命令复制(AOF)+文件复制(RDB),异步+半同步。
- MySQL:命令复制(Statement)+数据复制(Row),异步+半同步。
- Hadoop/ZooKeeper:独裁式决策(依赖ZooKeeper集群)。
- MongoDB:民主式选举(Raft算法)。
5. 核心结论
- 高可用本质:通过冗余应对故障,集群是必然选择。
- 设计核心:状态决策机制(独裁/协商/民主)决定架构复杂度。
- 数据复制权衡:一致性、性能、故障容忍度需平衡。
- 与高性能对比:高可用更复杂(需冗余管理、状态决策、异常处理)。
图片