冗余与容错 = 用不可靠元件构造可靠系统
解决什么问题：如何用不可靠的元件构造可靠的系统—— 不是让每个元件都可靠，而是通过冗余设计 + 容错机制保证整体可靠性。
业务问题
真实场景
场景 1：硬件故障
业务：服务器硬件会故障
问题：
- 磁盘有 MTBF
- 网络会中断
- 电源会失效
如何保证业务不中断？
→ 冗余：多副本
→ 容错：故障自动切换场景 2：软件 bug
业务：软件一定有 bug
问题：
- 即使测试充分，也有未知 bug
- 部署后可能出现 bug
如何保证业务不中断？
→ 冗余：灰度发布 + 多版本
→ 容错：自动回滚场景 3：人为错误
业务：人会犯错
问题：
- 配置错误
- 操作失误
- 误删除
如何保证业务不中断？
→ 冗余：变更审核 + 多环境
→ 容错：自动恢复失败的典型做法
做法 1：追求单一可靠
✗ 试图让每个元件都 100% 可靠
✗ 成本极高
后果：成本失控 / 仍然不可靠做法 2：没有冗余
✗ 单点故障
✗ 一台机器挂了 = 业务中断
后果：可用性差做法 3：冗余但不切换
✗ 多副本但故障时不切换
✗ 仍然不可用
后果：冗余无效控制论视角
数学原型
钱学森《工程控制论》Ch 19 §19 引言：
"冗余技术是用不可靠元件构造可靠系统的关键——单个元件可能失效，但通过冗余 + 容错，系统整体的可靠性可以任意高。"
数学依据：并联系统的可靠性 = 1 - ∏(1 - Rᵢ) 其中 Rᵢ 是单个元件的可靠性。
控制论解法
冗余与容错的核心：
冗余：
- 多副本（多机器、多版本、多路径）
- 提高单个元件失效不导致整体失效的概率
容错：
- 检测故障
- 隔离故障
- 切换到冗余副本
- 自动恢复
数学：
- 单个元件可靠性 = R
- 冗余 N 个副本：系统可靠性 = 1 - (1-R)^N
例：
- R = 99%（单机器可用率）
- 2 个副本：R_sys = 1 - 0.01^2 = 99.99%
- 3 个副本：R_sys = 1 - 0.01^3 = 99.9999%与业务的对应
| 控制论概念 | 软件工程 |
|---|---|
| 元件 | 服务器 / 服务 / 数据库 |
| 冗余 | 多副本 / 多机房 / 多版本 |
| 容错 | 自动切换 / 故障转移 |
| 系统可靠性 | 整体可用性 |
| 故障检测 | 健康检查 |
| 故障隔离 | 服务隔离 / 熔断 |
核心概念
定义
冗余：通过多个副本提供超出单副本能力的可靠性。
容错：在故障发生时自动恢复，保证业务不中断。
软件工程对位：高可用架构、容灾系统。
冗余的类型
| 类型 | 含义 | 软件工程对位 |
|---|---|---|
| 硬件冗余 | 多个物理设备 | 多服务器、多机房 |
| 软件冗余 | 多版本代码 | 灰度发布、A/B 测试 |
| 时间冗余 | 重试机制 | 自动重试 |
| 信息冗余 | 校验码 | 数据校验、纠错码 |
| 功能冗余 | 多种实现方式 | 多技术栈、多算法 |
关键属性
| 属性 | 含义 |
|---|---|
| 多副本 | 多个元件并行 |
| 故障检测 | 自动发现故障 |
| 故障隔离 | 故障不影响其他 |
| 自动切换 | 故障时自动切换 |
| 自动恢复 | 故障恢复后自动加入 |
冗余级别
| 级别 | 含义 | 适用场景 |
|---|---|---|
| 本地冗余 | 同机房多副本 | 应对单机故障 |
| 同城冗余 | 同城多机房 | 应对机房故障 |
| 异地冗余 | 跨地域多机房 | 应对地域故障 |
| 全球冗余 | 全球多地域 | 应对大规模灾难 |
工程实践
步骤 1：识别关键路径
关键路径：
- 业务核心流程
- 用户必经的服务
- 数据强一致的环节
非关键路径：
- 辅助功能
- 推荐 / 营销
- 数据分析步骤 2：设计冗余策略
冗余策略设计：
1. 副本数：
- 关键服务：3 副本（同机房）/ 5 副本（跨机房）
- 数据库：主从 / 主主 / 多主
- 缓存：3 副本
2. 部署策略：
- 同机房：低延迟
- 跨机房：可用性高
- 跨地域：抗灾
3. 数据冗余：
- 数据同步：同步 / 异步
- 备份：本地 / 异地步骤 3：设计容错机制
容错机制设计：
1. 故障检测：
- 健康检查（每 10 秒）
- 心跳（每 30 秒）
- 业务监控（实时）
2. 故障隔离：
- 熔断（避免故障传播）
- 降级（牺牲非核心功能）
- 限流（避免过载）
3. 故障切换：
- 主从切换（数据库）
- 流量切换（服务）
- DNS 切换（机房）
4. 故障恢复：
- 自动重启
- 数据同步
- 服务加入步骤 4：测试容错能力
测试方法：
1. 故障注入：
- 注入网络故障
- 注入机器故障
- 注入服务故障
2. 混沌工程：
- Chaos Monkey
- Litmus
- Gremlin
3. 容灾演练：
- 切换主从
- 切换机房
- 切换地域步骤 5：持续改进
持续改进：
- 每次故障后 review
- 改进检测机制
- 改进恢复机制
- 改进预防机制常见反模式
反模式 1：单点故障
症状：
- 关键路径只有 1 个副本
- 故障 = 业务中断
后果：可用性差
正解：冗余反模式 2：冗余但不切换
症状：
- 多副本但故障时不切换
- 仍然不可用
后果：冗余无效
正解：自动切换反模式 3：没有测试
症状：
- 设计了冗余
- 但没测试过
后果：故障时切换失败
正解：定期演练工程实例
实例 1：数据库高可用
业务：MySQL 数据库
冗余设计：
- 主从复制（1 主 2 从）
- 跨机房部署（主在机房 A，从在机房 B、C）
- 数据同步：半同步复制
容错设计：
- 健康检查（每 5 秒）
- 主从切换（30 秒内完成）
- 故障自动检测（VIP 漂移）
- 数据补偿（异步同步）
切换流程：
1. 主库故障
2. 从库检测（10 秒）
3. 选择新主（最新数据）
4. 提升为主（30 秒）
5. VIP 漂移到新主
6. 应用自动重连
可用性：
- 单机：99.9%
- 主从：99.99%
- 跨机房：99.999%实例 2：微服务高可用
业务：订单服务
冗余设计：
- 3 副本（不同机器）
- 跨可用区部署
- 负载均衡
容错设计：
- 健康检查（每 10 秒）
- 熔断（下游故障时）
- 降级（牺牲非核心功能）
- 限流（避免过载）
故障处理：
1. 单副本故障 → 剩余 2 副本继续服务
2. 整个机房故障 → 切换到其他机房
3. 下游故障 → 熔断 + 降级
4. 流量激增 → 限流 + 扩容
可用性：
- 99.95%+实例 3：异地容灾
业务：核心业务
设计：
- 主机房（北京）
- 灾备机房（上海）
- 数据异步同步
切换流程：
1. 主机房故障
2. 灾备系统检测
3. DNS 切换到灾备机房
4. 灾备机房接管（5 分钟内）
5. 数据反向同步
RTO（恢复时间目标）：5 分钟
RPO（恢复点目标）：1 分钟
成本：
- 灾备机房：正常 50% 容量
- 平时：流量 100% 在主机房
- 灾备演练：每月一次性能指标
冗余容错健康指标
| 指标 | 设计目标 | 衡量方法 |
|---|---|---|
| 可用性 | > 99.95% | uptime |
| MTTR | < 5 分钟 | 故障恢复时间 |
| RTO | < 设计目标 | 切换时间 |
| RPO | < 设计目标 | 数据丢失 |
| 容灾演练频率 | 每月 1 次 | 演练次数 |
监控设计
关键监控：
- 可用率（按服务、按机房）
- MTTR（故障恢复时间）
- 切换次数
- 数据同步延迟
- 容灾演练
告警分级：
- P2：单副本故障
- P1：可用率 < 设计目标 / MTTR > 设计目标
- P0：整体故障 / 容灾切换边界判断
何时不用
场景 1：业务可容忍中断
- 离线业务
- 用户可等待
→ 不需要高可用场景 2：业务极简
- 没有关键路径
- 故障影响小
→ 不需要冗余场景 3：成本限制
- 冗余成本太高
- 业务价值不高
→ 评估 ROI与其他方法论的边界
| 相邻概念 | 区别 |
|---|---|
| 自镇定与自适应 | 自镇定关注"无模型稳定"；本方法论关注"可靠性" |
| 大系统理论 | 大系统关注"协调"；本方法论关注"可靠性" |
| 备份 | 备份是数据冗余；本方法论是系统冗余 |
何时升级（更复杂的高可用）
当以下情况出现时，考虑升级：
1. 业务规模指数增长 → 多活架构
2. 全球化业务 → 全球多活
3. 业务关键性极高 → 异地多活
4. 故障频发 → 全面容灾关键洞察
钱学森 Ch 19：冗余与容错是用不可靠元件构造可靠系统的核心方法。
软件工程的高可用智慧：
不是让每个元件都 100% 可靠——而是让系统整体 100% 可靠。
数学依据：
- 单机可靠性 R
- N 个副本：R_sys = 1 - (1-R)^N
- N 越大，可用性越高
应用场景：
- 数据库 → 主从 / 主主 / 多主
- 微服务 → 多副本 + 跨可用区
- 灾备 → 异地多活
- 配置 → 多版本 + 自动回滚
好的冗余容错 = 适当的副本数 + 快速切换 + 定期演练
相关链接
IDDD 对位
核心：冗余容错 = 故障可恢复——IDDD 仓储重试和 cybernetics 冗余设计同构。