可用性的度量AVAILABILITY MATH
可用性（Availability）定义为服务可用时间占总时间的比例，即"可用时间 / 总时间"。 工程上以小数点后的"9"分级：每提升一个 9，全年可容忍的停机预算缩减一个数量级，而架构成本通常成倍上升—— 先定目标再选架构，是高可用设计的第一步。按 365 天折算的常见等级如下：
| 可用性等级 | 年停机预算（按 365 天） | 月停机预算（按 730 小时） | 典型适用场景 |
|---|---|---|---|
| 99% | ≈ 87.6 小时 | ≈ 7.3 小时 | 内部工具、非关键后台 |
| 99.9% | ≈ 8.76 小时 | ≈ 43.8 分钟 | 一般对外业务、企业官网 |
| 99.95% | ≈ 4.38 小时 | ≈ 21.9 分钟 | 电商、付费会员服务 |
| 99.99% | ≈ 52.6 分钟 | ≈ 4.4 分钟 | 交易、支付等核心链路 |
表 1 · 可用性等级与停机预算换算（SRE 实践的通用口径[2]）
RTO（Recovery Time Objective）= 故障发生到恢复服务的目标时长，衡量"多久能恢复"； RPO（Recovery Point Objective）= 可容忍的数据丢失时间窗口，衡量"丢多少数据"。两者由业务方确定， 架构冗余与备份策略只是实现手段——RTO/RPO 定不下来，后面的投入就没有验收标准。
冗余架构谱系REDUNDANCY LADDER
冗余是高可用的根本手段：用多余的组件承接失效组件的工作。冗余谱系从单机到多地域逐级上升， 每一级覆盖的故障范围更大，成本也更高。选型的依据是表 1 定下的停机预算——预算越紧，需要的层级越高：
| 架构层级 | 典型实现 | 可覆盖的故障 | 成本倍数 |
|---|---|---|---|
| 单机 | 单节点承载全部服务 | 进程级故障（崩溃重启、热修复） | 1× |
| 主备 | 冷备（数据同步、平时不接流量）／热备（keepalived VIP 漂移自动接管）[5] | 整机宕机、系统盘损坏 | ≈ 2× |
| 双活 | 负载均衡挂双节点同时服务，健康检查剔除故障侧 | 单侧故障、滚动升级不停服 | 2–3× |
| 多地域 | 异地容灾，DNS / 全局负载均衡切换 | 地域级灾难、运营商骨干故障 | 3× 以上 |
表 2 · 冗余架构谱系（成本倍数为经验量级参考，以实际采购与运维投入为准）
常见的误区是"直接上多地域"：多数业务的真实故障集中在单机与进程级，主备加自动切换已能消化 绝大多数停机；而地域级容灾引入的数据一致性与切换演练复杂度，往往超出团队能承受的运维半径。 升级顺序应当是"故障统计驱动"——哪一级故障在复盘里反复出现，就把冗余补到哪一级。
参考架构REFERENCE ARCHITECTURE
对外提供 Web / API 服务的业务，参考架构为四段式。各层无状态化之后，任何一层都可以独立替换与扩容：
图 1 · 高可用参考架构（单点收敛在负载均衡，数据层是唯一有状态层）
健康检查是自动切换的前提：负载均衡按固定间隔探测节点，连续判死即摘除流量。 工程常用探测间隔 5 秒、连续 3 次失败判死（经验值，以业务实际响应时间为准），对应故障摘除时间 约 15–20 秒；支付回调等敏感链路可缩短间隔，但探测超时不宜收得过紧，否则正常但繁忙的节点会被误摘， 切换本身反而制造故障。
无状态化的意义在于让"节点"变成可抛弃的：会话放到 Redis，文件放到对象存储或 共享存储，本地只保留代码与临时缓存。做到这一点，扩容就是加节点、故障恢复就是换节点， 不再需要任何数据搬迁——这也是应用节点可以写成"× N"的前提。
数据保护策略DATA PROTECTION
架构冗余解决"服务不中断"，数据保护解决"数据不丢失"。两条主线各自成立、缺一不可：
主从复制与半同步：主库写入、从库实时回放，是数据库高可用的基础形态[4]。 异步复制在主库宕机时可能丢失最后一段事务；半同步复制要求至少一个从库确认收到 binlog 后主库才返回成功， 用少量写延迟换取更小的 RPO——交易类业务建议至少半同步。
3-2-1 备份原则：至少 3 份数据副本、存放在 2 种不同介质、其中 1 份异地 （另一机房或另一地域）。备份与主库共享任何单点（同一台机器、同一存储、同一供电）， 都会让"备份"在真实灾难中与原件同时失效。
没有做过恢复演练的备份等于没有备份：备份文件损坏、恢复步骤缺失、依赖配置遗漏，都只在真正恢复时暴露。 建议每季度做一次完整恢复演练，把恢复耗时记录为实测 RTO，并据此修正备份频率与保留策略。
形态选择上：核心库建议 物理服务器 独占，避免宿主机资源争抢影响复制延迟； 一般业务用 弹性云主机 配合自动快照即可；需要多节点组合的团队可参考 裸机云，本站机型均支持免费真机测试[6]， 复制延迟与切换耗时都应在下单前实测。
实施清单CHECKLIST
高可用不是一次性工程，而是"目标—演练—复盘"的循环。上线与运行期逐项核对：
- 先定目标：明确业务可用性目标（99.9% 还是 99.99%），两者的架构与成本差数倍，目标不清会导致投入错位。
- 故障演练：在低峰期主动拔线、杀进程、重启主库，验证切换是否自动完成、耗时是否落在 RTO 之内。
- 监控告警全覆盖：节点存活、复制延迟、磁盘水位、证书到期，任一项缺失都会把"高可用"变成"看起来可用"。
- 预案文档与值班表：自动切换失败时的人工步骤、升级路径与联系人，写成可执行文档并随演练更新。
- 季度复盘：统计每次故障的发现方式、恢复耗时与根因，对照年度停机预算检查消耗速度。
小结SUMMARY
高可用方案的决策链可以压缩为四步：定目标（99.9% 与 99.99% 的成本差数倍，先用表 1 量化停机预算）→ 定冗余层级（多数业务主备或双活即可，不必直接上多地域）→ 定数据策略（半同步复制 + 3-2-1 备份 + 季度恢复演练）→ 定演练节奏（主动制造故障，用实测 RTO 验证架构）。 行业停机分析反复显示，长时间事故多源于变更与人为操作[1]—— 流程与演练的收益，不亚于任何一层硬件冗余。