3. 高可用基础概念

高可用（High Availability，HA）不是一句“系统不要挂”的口号，而是一组可以被度量、被承诺、被验证的工程约束。要设计高可用架构，首先必须把“可用”翻译成数字：可用性百分比、SLA 承诺、RTO 与 RPO。只有指标清晰，冗余、故障域隔离和容错设计才有明确的投入方向与验收标准。

一、可用性指标：把“稳定”变成可计算的数字

可用性通常用“正常运行时间 / 总时间”表示，工程上习惯用“几个 9”来沟通。它直接决定了每年、每月允许的中断时长，也决定了架构成本：从 99% 到 99.99%，每提升一个数量级，往往意味着冗余、自动化、演练和监控成本的显著上升。

可用性等级	年允许中断	月允许中断	典型场景
99%（2 个 9）	约 87.6 小时	约 7.3 小时	内部测试、非核心系统
99.9%（3 个 9）	约 8.76 小时	约 43.8 分钟	一般业务系统
99.99%（4 个 9）	约 52.6 分钟	约 4.38 分钟	核心交易、支付
99.999%（5 个 9）	约 5.26 分钟	约 26 秒	电信级、金融关键链路

需要注意的是，可用性指标必须定义“什么算不可用”。是接口错误率超过阈值，还是响应时间超过 P99？是整站不可访问，还是某个租户不可用？如果口径不统一，SLA 就会变成争议来源。

二、SLA、RTO、RPO：承诺、恢复目标与数据损失边界

SLA（Service Level Agreement）是服务方与使用方之间的可用性承诺，通常包含可用性百分比、响应时间、故障响应时限、赔偿条款等。SLA 不是技术指标本身，而是技术能力与商业承诺的交汇点。它向下驱动架构设计，向上支撑合同与信任。

RTO（Recovery Time Objective）是恢复时间目标，回答“故障发生后，多久必须恢复服务”。RPO（Recovery Point Objective）是恢复点目标，回答“最多允许丢失多长时间的数据”。两者共同决定了备份策略、复制方式、切换机制和演练频率。

例如，某订单系统承诺 99.99% 可用性，RTO 为 5 分钟，RPO 为 0。这意味着：故障切换必须自动化，且主备之间不能有异步复制窗口。若采用异步复制，RPO 可能是秒级甚至分钟级，就无法满足承诺。

三、单点故障、冗余与故障域：高可用的结构基础

单点故障（SPOF）是指系统中一旦失效就会导致整体不可用的组件。它可能是一台数据库、一个负载均衡器、一条专线、一个 DNS 记录，甚至是一个只有一个人掌握的运维流程。识别 SPOF 是高可用设计的第一步。

冗余是消除 SPOF 的主要手段，但冗余不等于高可用。冗余必须满足三个条件：可检测、可切换、可验证。如果备用节点故障时无人知晓，或者切换需要人工介入 30 分钟，那么冗余只是心理安慰。

故障域（Failure Domain）是指一个故障能够影响的最大范围。高可用架构的核心原则之一是“不要把鸡蛋放在同一个故障域”。同一机架、同一交换机、同一可用区、同一电源、同一版本发布批次，都是潜在的故障域。跨故障域部署，才能让局部故障不扩散为全局故障。

四、容错设计原则：从“不出错”转向“出错也能扛”

容错设计的核心思想是：假设故障一定会发生，系统要在部分组件失效时仍能提供可接受的服务。常见原则包括：

• 隔离：通过舱壁模式、线程池隔离、租户隔离，防止一个慢依赖拖垮整个服务。
• 降级：非核心功能在压力或故障时自动关闭，保障核心链路。
• 限流与熔断：限制入口流量，熔断持续失败的依赖，避免雪崩。
• 超时与重试：为每个远程调用设置合理超时，重试必须配合退避与幂等。
• 幂等：重试和切换场景下，重复请求不能产生重复扣款、重复下单。
• 自动化切换：故障检测与流量切换尽量自动完成，减少人工介入时间。

五、案例与场景：一次数据库主库故障的复盘

某电商系统采用 MySQL 主从架构，主库故障后由运维手动切换，平均耗时 25 分钟。SLA 承诺 99.99%，RTO 为 5 分钟，RPO 为 0。一次主库磁盘故障导致订单写入中断 28 分钟，直接违反 SLA。

复盘发现三个问题：第一，主从复制为异步模式，RPO 实际为秒级，不满足 0；第二，切换依赖人工判断和脚本执行，RTO 远超 5 分钟；第三，监控只告警“主库不可用”，没有自动触发切换。改进方案包括：引入半同步复制降低 RPO，部署自动故障切换组件，增加切换演练和回切验证。

# 故障切换检查清单示例
1. 确认主库不可用：连续 3 次心跳失败
2. 确认从库延迟：Seconds_Behind_Master = 0
3. 提升从库为主库：STOP SLAVE; RESET SLAVE ALL;
4. 切换 VIP / DNS 指向新主库
5. 验证写入：INSERT 测试并回滚
6. 通知上游服务刷新连接池
7. 记录切换时间，核对 RTO / RPO

六、常见误区与复盘要点

• 误区一：有备份就等于高可用。备份解决数据恢复，不解决服务连续性；RTO 可能长达数小时。
• 误区二：冗余越多越好。冗余增加一致性、成本和运维复杂度，必须与 RTO/RPO 匹配。
• 误区三：SLA 只是商务条款。SLA 必须转化为技术指标，并落到监控、告警和演练中。
• 误区四：故障域只看机房。同一版本、同一配置、同一证书、同一依赖服务都可能是故障域。
• 误区五：切换成功就结束。回切、数据校验、连接池恢复、缓存一致性同样关键。

总结来说，高可用基础概念构成了一条清晰的工程链路：用可用性指标和 SLA 定义目标，用 RTO 和 RPO 约束恢复能力，用单点故障识别风险，用冗余和故障域隔离构建结构，用容错设计原则保障故障时的服务连续性。理解并量化这些概念，是后续性能优化与高可用架构设计的前提。