高可用设计：冗余、故障转移与降级边界

服务部署了十个实例，数据库有一个主库和两个副本，消息队列也配了三副本。某个可用区故障后，请求仍可能全部失败：健康检查误杀剩余实例，负载均衡把流量压到不足的容量上，数据库提升了落后的副本，旧主恢复后继续接受写入，应用又因为配置中心不可用而无法连接新主。

副本解决的是“还有另一份计算或数据”，高可用还要解决“什么时候切、由谁接管、旧所有者怎样退出、剩余容量是否够用、切换期间交付什么结果”。这些步骤任何一项失效，冗余都可能停留在架构图上。

本文回答的问题是：副本已经存在时，怎样检测故障、选出唯一接管者、保证备用容量，并在无法安全接管时退到明确的业务能力边界？讨论范围是实例、节点、依赖和单可用区级别的日常故障。整个 Region 或机房消失后的数据恢复、RPO 与 RTO，已在一个机房整体故障后怎样恢复中展开。

一、高可用先是一份用户可观察的契约

可用性常用成功请求占比表示：

availability = good_events / valid_events

good_events 需要同时满足结果正确和延迟达标。一个接口最终都返回 200，但 10% 请求耗时 30 秒，不能按 100% 可用计算。Google SRE 的 SLI/SLO 说明也建议从用户关心的服务水平定义指标，并指出客户端延迟往往比服务端指标更接近真实体验。

“几个 9”必须换成失败预算

按一个 30 天月份估算：

月度可用性	允许不可用时间	平均每天可失败比例
99%	约 7.2 小时	1%
99.9%	约 43.2 分钟	0.1%
99.95%	约 21.6 分钟	0.05%
99.99%	约 4.32 分钟	0.01%

这只是时间近似。流量随时间变化时，按请求成功率统计更合理：凌晨十分钟与大促十分钟影响的用户数量不同。Google SRE 可用性表也区分按时间与按请求聚合的可用性。

SLO 还要按能力拆分。支付查询可以是 99.99%，新支付创建是 99.95%，报表导出是 99.9%。如果把所有接口揉成一个平均数，报表大量成功可能掩盖扣款故障；反过来，低价值接口的失败也会迫使核心链路承担不必要的成本。

高可用、可靠性、持久性和灾备各有边界

概念	关心的问题	一个典型反例
可用性	此刻能否在时限内正确服务	数据都在，但入口全部超时
可靠性	一段时间内能否持续正确工作	每天自动切主一次，用户频繁抖动
持久性	已确认数据是否会长期保留	服务在线，但故障后丢了已提交订单
灾难恢复	大故障后多久恢复到哪个数据点	同 Region 高可用，Region 消失后无恢复路径

提高可用性不能以静默返回错误数据为代价。数据库副本落后时强行提升，接口很快恢复 200，已确认订单却消失；从成功率看似“可用”，从业务看已经破坏正确性。因此高可用契约必须包含数据确认点、允许的陈旧度和结果未知时的处理方式。

二、先画故障域，再摆副本

两台机器若位于同一宿主机、机架、电源或可用区，它们会被同一次故障带走。副本数量只有和故障域结合才有意义。

常见故障域从小到大包括：进程、容器或虚拟机、宿主机、机架、交换机、可用区、Region，以及共享的控制面、账号和发布系统。业务层还有逻辑故障域，例如同一租户、同一分片、同一个软件版本和同一配置。

从用户请求到共享依赖的故障域

共享依赖需要单独标出。应用跨三个可用区部署，却共用单可用区 Redis、NAT、配置中心或数据库主节点，整体故障域仍被这些组件决定。三个区域都发布同一份错误配置，则硬件隔离也无法阻止相关失败。

依赖串联会压低端到端可用性

一条请求必须依次通过网关、服务、数据库和权限系统。若四个组件独立且各有 99.9% 可用性，粗略乘积为：

0.999⁴ ≈ 99.6006%

现实中的故障往往相关，不能把这个公式当成精确预测，但它提醒我们：每个强依赖都会消耗端到端预算。可选推荐、通知和埋点不应进入核心交易的同步成功条件；能够异步补做的工作应在核心提交后执行。

并联冗余的理想公式是 1 - (1-A)^N，前提是副本独立、流量能自动绕过故障，并且共享依赖没有同时失效。两个 99% 副本只有在这些条件成立时才接近 99.99%。同版本 bug、同一数据库、错误健康检查与容量不足都会破坏独立性假设。

用 Cell 限制一次故障影响多少用户

当一套超大集群服务所有用户时，一条异常数据、一个重查询或一次错误配置都可能消耗整个集群的资源。继续给这套集群加副本可以提升容量，却没有缩小故障波及范围。Cell 架构把系统切成多个容量有上限、彼此尽量独立的服务单元，每个 Cell 拥有完成请求所需的计算、缓存、队列和数据分片。用户或租户通过稳定规则映射到某个 Cell，一个 Cell 失效时只影响其中一部分用户。

AWS Well-Architected 对 Cell 的定义强调两个特征：Cell 是相对独立的完整服务单元，并且有明确的最大规模；系统通过增加 Cell 扩展，而不是无限扩大已有 Cell。容量上限使压测结论可以复用，也让故障的最大爆炸半径可以估算。

Cell 和可用区不是同一层概念。一个 Cell 自身可以跨多个可用区部署，以承受单区故障；同一 Region 内再放置多个 Cell，用来隔离租户、发布批次和资源争抢。前者提高一个 Cell 的可用性，后者限制一个 Cell 故障时的影响范围。

引入 Cell 后还要约束跨 Cell 调用。若每次请求都同步访问中心数据库、全局缓存和其他 Cell，它们又组成了新的共享故障域。路由目录应有缓存和静态回退，跨 Cell 统计尽量异步汇总，发布按 Cell 分批推进。对于难以完全拆分的无状态工作池，也可以让每个租户只使用一小组固定 worker，减少不同租户共享相同故障节点的概率；这种 shuffle sharding 思路仍不能替代有状态数据的明确归属。

三、无状态服务适合多活，有状态服务需要唯一所有者

无状态实例不持有请求之间必须延续的权威状态。多个实例同时接流量，只要依赖和配置一致，某个实例退出后负载均衡可以把新请求发给其他实例。这是 active-active 多活。

用户会话若只在本地内存中，实例就不再完全无状态。故障转移后登录丢失，或者负载均衡必须使用 sticky session。更稳妥的做法是把必要会话放到具备独立高可用设计的状态存储，或者使用可验证的自包含令牌，并明确撤销语义。

多活容量按失去一个故障域后计算

三个可用区各承担三分之一流量，每区已经运行在 80% 安全容量。失去一区后，剩余两区各要承担约 50% 总流量，负载从 80% 升到 120%，很快进入过载。副本还在，服务仍会级联失败。

高可用容量条件可写成：

remaining_safe_capacity_after_failure >= peak_accepted_load

AWS Builders’ Library 的可用区静态稳定性给出一个三可用区示例：每区运行在压测能力的约 66%，这样失去一区后，剩余两区不需要临时启动新实例就能承接负载。具体比例应使用自己的安全容量、峰值和故障域计算。

“故障后自动扩容”可以补充容量，不能成为唯一恢复路径。事故时控制面、镜像仓库、配额、启动依赖或节点资源可能同时异常；新实例还会冷启动、建连接和回源缓存。静态稳定要求在故障发生前就准备好维持核心服务的容量。

有状态主备的难点是写权限转移

数据库、分区 leader 和调度器通常在一个时刻只有一个写入所有者。备用副本持续复制状态，主节点失效后需要选择候选者、提升为新主、通知客户端，并阻止旧主继续写。

active-standby 的可用性取决于四项：备用数据是否足够新，选主能否唯一，客户端能否发现新地址，备用容量能否立即承担负载。任何一项没有演练，主备都只是数据复制方案。

四、健康检查要区分“活着”“就绪”和“能服务”

进程端口可连接，只能证明内核和监听 socket 还在。线程池耗尽、数据库连接全部等待、关键配置未加载时，实例仍可能无法在 deadline 内完成请求。反过来，一个依赖短暂抖动也不代表应该重启进程。

Kubernetes 将探针拆为三类：startup probe 给慢启动留出窗口；readiness probe 决定是否接收流量；liveness probe 判断是否需要重启容器。官方文档特别警告错误的 liveness 会制造级联故障，因为探针失败会让平台杀掉仍可能恢复的实例。

探针回答的问题必须单一

启动探针：初始化是否已经完成，可以开始其他周期检查吗？
存活探针：进程是否陷入只能靠重启恢复的状态？
就绪探针：此刻把新请求发来，实例是否有能力处理？
深度业务探针：从入口到关键依赖的最小交易是否成功？

不要让 liveness 同步检查所有下游。数据库短时超时会让所有应用实例同时判死并重启，连接风暴又进一步压垮数据库。readiness 可以在关键依赖失效时暂时摘流，但也要防止所有实例同时退出负载均衡。服务整体过载时，比摘除全部实例更合理的动作通常是拒绝部分流量并保留健康容量。

检测窗口是在速度与误判之间取舍

每秒探测一次、连续三次失败后摘除，理论检测时间约为 3 秒，再加传播和连接排空。把阈值改成一次失败可以更快，却会把单个丢包或 GC 暂停当成故障。阈值还要考虑探针发起位置：节点本地探针、负载均衡探针和外部用户探针看到的网络路径不同。

黑白故障容易判断，灰色故障更难。某实例只对一个可用区、一个请求类型或大包超时，本地 /healthz 仍然成功。需要结合真实请求的被动异常检测、分区维度 SLI 和外部探针。实例摘除与服务级熔断的区别已在服务发现、健康检查与故障摘除中详细讨论。

五、故障转移是一条有顺序的状态机

一次可靠接管通常经历：发现异常、确认故障域、停止新流量、隔离旧所有者、选择并提升候选者、传播新路由、预热验证、逐步恢复流量。不同系统会合并步骤，约束不会消失。

有状态服务的故障检测与接管状态机

先隔离旧主，再授予新主写权限

监控看不到旧主，可能是旧主宕机，也可能是监控与旧主之间网络分区。后者仍可能服务另一批客户端。直接提升副本会形成双主。

隔离可使用存储租约、任期或 epoch、撤销数据库账号、关闭旧节点磁盘、仲裁服务，或者让资源端只接受当前 fencing token。新主获得更高 epoch 后，旧主即使恢复网络，其写入也会被权威存储拒绝。只修改服务发现地址不能阻止旧连接和绕过发现的内部任务继续写。

Redis Sentinel 的高可用文档展示了这类仲裁：配置的 quorum 决定多少 Sentinel 同意主节点客观下线，实际执行 failover 还需要 Sentinel 多数派授权，并为每次配置分配唯一 epoch。少数网络分区不会自行提升主节点。

候选者选择要考虑复制位置

备用副本并非同样新。选主至少要比较已持久化或已应用的日志位置、复制健康、故障域、优先级和节点负载。提升落后副本会扩大数据缺口；等待最新副本恢复会延长不可用时间。这是持久性和可用性的显式取舍。

Kafka 对 leader 丢失也暴露类似选择。Kafka 设计文档说明，默认倾向等待一致副本；开启 unclean leader election 可以从非同步副本中选 leader，提高恢复机会，但可能丢失已提交到旧 leader、尚未存在于候选副本的数据。这个开关表达的是业务取舍，不是一项无条件的“高可用优化”。

地址传播后还要处理旧连接

客户端可能缓存 DNS、连接池或 leader 元数据。新主已经就绪，旧连接仍可能持续超时。客户端需要在明确错误后刷新路由、重建连接，并对结果未知的写请求使用相同业务幂等键查询或重试。

故障切换不能让每一层都立即重试。成千上万客户端同时刷新、建连、认证和补发请求，会形成恢复洪峰。连接退避加入 jitter，服务端限制握手和重放并发，负载均衡按批次恢复流量。

六、数据确认级别决定切换时可能丢什么

三副本不等于每次写都已到三份。写入可能在主节点本地落盘后返回，也可能等待一个副本或多数副本。确认点越强，正常延迟和分区时不可用概率越高；确认点越弱，主节点突然消失时的数据缺口越大。

设计表中应明确：

数据	返回成功前等待什么	自动切换允许的候选者	切换后校验
账户流水	多故障域持久化或数据库提交保证	满足提交点的最新副本	业务号连续性、账务对账
普通订单	主库提交 + 已约定复制级别	不低于安全日志位点	订单号、状态机扫描
搜索索引	本地接受事件即可	任意可重建节点	与事实库抽样核对
缓存	可只写主缓存	空节点或可用副本	限速回源、热点预热

数据系统还要区分已接收、已写内存、已落本地盘、已复制、已应用和已对外可读。监控只显示“副本在线”，无法证明它满足提升条件。

自动故障转移会产生结果未知

客户端发送创建订单，主库提交成功后在响应途中故障。新主接管后订单已经存在，客户端只看到超时。若客户端换一个新订单号重试，就会创建两笔订单。高可用切换没有消除分布式调用的不确定性。

写接口应接收稳定业务号，重复请求返回同一业务结果；客户端先按业务号查询，再决定是否重试。关于 RPC 的成功、失败和结果未知可参见RPC：一次远程调用可能处于哪些状态。

七、控制面失效时，数据面要维持已有服务

控制面负责部署、扩容、配置、服务注册和路由计算；数据面负责处理已经建立的业务流量。高可用系统应尽量让数据面保留最近一份有效配置，在控制面短暂不可用时继续工作。

例如配置中心故障时，服务可以继续使用已验证的本地快照，拒绝新的配置变更；服务发现不可用时，客户端在 TTL 内使用旧 endpoint，并通过被动失败摘除坏节点；限流中心暂时不可用时，实例采用预分配的本地保守额度。默认行为要按风险选择，不能一律 fail open。

AWS 的静态稳定性文章将这种能力描述为控制面受损时，数据面继续执行已有工作。恢复路径若依赖故障发生后新建实例、下载配置、申请权限和修改网络，会同时依赖多个可能受影响的控制面。

静态配置也有陈旧风险。权限撤销、证书轮换与紧急封禁不能无限使用旧值，需要最大有效期和安全失败策略。数据面只能在约定窗口内维持已知安全状态，超过窗口仍要重新取得控制面更新。

八、故障转移会把容量问题暴露出来

正常时四个实例各承接 25% 流量，一个实例故障后其余三个各承接约 33%，相对负载上升三分之一。如果它们原先已接近拐点，故障转移会把健康实例也推入高延迟，探针失败后继续被摘除，形成容量雪崩。

Google SRE 的级联故障章节专门描述了这条正反馈：副本失效使剩余副本负载上升，后者因过载继续失效。恢复时需要把流量降到当前健康容量之下，而非原集群的额定容量。

备用容量要覆盖整条依赖链

应用还有 CPU 余量，数据库连接池可能已满；数据库副本可接管，NAT、网关或消息 broker 的单区容量可能不足。每个故障场景都要计算整条链路在 N-1 状态下的瓶颈：

failover_capacity = min(
  remaining_gateway,
  remaining_app,
  remaining_db,
  remaining_cache,
  remaining_dependency_quota
)

缓存也会在切换后变冷。新实例或新可用区同时回源，数据库承受的压力可能高于正常峰值。热点数据应预热，普通 miss 使用请求合并与源站限流；离线补偿、扫描和报表任务要暂停或降低优先级，把容量留给在线请求。

回流需要渐进，而不是探针一绿就满载

刚恢复的实例可能仍在 JIT、加载索引、建立连接和填充缓存。readiness 成功后先接受少量流量，观察真实请求延迟和错误，再逐步提高权重。探针成功只能证明一个廉价路径成功，无法证明实例已经具备满载能力。

九、降级边界是一张业务能力阶梯

故障时“系统可用”不一定代表所有功能完整。合理做法是提前定义能力等级，故障处理器只能沿批准的阶梯下降。

故障期间的业务能力降级阶梯

以活动报名为例：

等级	可提供能力	触发条件	禁止行为
L0 完整	报名、取消、查询、推荐、通知	全部核心依赖健康	无
L1 精简	报名与查询；推荐和实时榜单关闭	非核心依赖故障或容量紧张	非核心调用占用核心池
L2 受理	返回排队中，异步判定报名结果	写库短时不可用，队列与幂等记录可靠	把受理说成报名成功
L3 只读	查询最后确认结果，停止新报名	无法安全确定唯一写主	接受任何需要强一致的新写
L4 关闭	明确不可用并给出可重试建议	权威数据和身份均不可用	返回缓存伪造成功

这张表的价值是划清正确性。推荐列表可以返回旧值，库存和支付结果不能凭缓存猜测；消息队列只有在消息可靠落地、业务允许稍后完成时才能支撑 L2；无法 fence 旧主时，退到只读通常比冒险双写安全。

fail open 与 fail closed 按风险选择

权限校验、扣款、库存最终确认通常在依赖不确定时 fail closed，即拒绝或返回处理中。内容推荐、头像与非关键配置可以 fail open 到缓存或默认值。风控比较特殊：低风险浏览可使用保守本地规则，高风险资金动作应阻止。

降级结果要进入接口契约。DEGRADED_STALE_READ、ACCEPTED_PENDING、READ_ONLY 与 UNAVAILABLE 应可被客户端区分，监控也能按状态统计。所有异常都返回 200 和空对象，会让调用方继续执行错误流程，也让 SLO 看起来虚假健康。

第 7 篇限流、熔断、隔离、降级与背压讨论单次请求怎样受到保护；这里的能力阶梯负责系统整体在不同故障阶段允许交付什么。

十、用活动报名链路走一遍可用区故障

假设系统跨 A、B、C 三个可用区部署：网关和报名服务无状态多活；MySQL 在 A 为主，B 为同步候选，C 有异步只读副本；Redis Cluster 分片与副本跨区；Kafka 每个关键 topic 三副本；正常峰值 18,000 QPS，两个可用区的安全容量合计为 24,000 QPS。

正常状态

每区承接约三分之一流量，实例保留故障余量。应用优先访问同区缓存和网关，关键数据写 MySQL 主库。报名使用 (activity_id, user_id) 幂等键；接口返回成功前等待数据库约定的提交点。队列中的通知与统计不影响报名事务。

B 区发生网络故障

外部探针发现 B 区用户请求失败，A、C 到 B 的跨区探针也异常。B 中应用 readiness 失败，负载均衡逐步停止新流量；liveness 不因数据库探测失败而集体重启。A、C 接管流量后，总需求 18,000 QPS 低于 24,000 的安全容量。

若 MySQL 候选正好在 B，数据库不切换，因为 A 主库仍健康。B 的 Redis 主分片由其他区副本在多数派授权后接管，客户端刷新拓扑。Kafka 只从满足同步条件的副本中选 leader，通知消费允许暂时积压。

A 区的数据库主节点随后故障

这是第二重故障。仲裁确认旧主失去租约，比较候选复制位置后提升仍满足安全提交点的副本。报名写接口短暂进入 L2 或 L3：如果可靠受理队列及其幂等状态可用，就返回排队中；若不能证明命令会被唯一处理，则只读并明确拒绝新报名。

客户端对超时请求使用原请求号查询。新主就绪后，报名服务刷新连接，以 1%、10%、50%、100% 恢复写流量；每一步检查数据库锁等待、连接数、复制状态和业务成功率。通知、榜单与数据扫描继续暂停。

B 区恢复

B 中实例先以零权重启动，加载配置与缓存，通过合成报名查询，再接收少量真实读流量。数据库副本从当前主追平后重新加入候选集，旧 epoch 的任务没有写权限。观察一个稳定窗口后恢复全部能力，最后才启动离线补偿。

这次演练还要记录用户失败率、最长不可用、结果未知请求数、数据差异、两区峰值利用率、每个阶段耗时，以及降级状态是否与前端展示一致，不能只留下“自动切换成功”这一项结论。

十一、灰色故障与相关故障比宕机难处理

进程完全退出，负载均衡很快能绕开。灰色故障只影响部分路径：某个可用区到数据库丢包，大请求被网络设备丢弃，IPv6 路径异常，某一租户数据触发死循环。全局成功率仍可能正常，受影响用户却持续失败。

诊断需要按可用区、实例、调用方、请求类型和租户拆分 SLI，并比较主动探针与真实流量。路由策略可以优先保持 zonal affinity，让同区故障尽量留在同一区；跨区回退只在本区路径失败后发生。否则每一跳都随机跨区，局部网络故障可能污染整条区域调用链。

相关故障常来自发布和配置。所有副本同时升级同一个 bug，冗余不会提供保护。发布应按实例、可用区和版本分批，保留能够承接流量的旧版本。数据库 schema 变更需要前后兼容窗口，使新旧应用能同时运行并快速回滚。

十二、演练要验证失去副本后的业务，而非只看组件

高可用能力只能通过故障中的观测证明。测试应从小范围开始，并在受控环境逐步扩大：

杀死单实例，验证摘流、连接排空与请求重试。
关闭一个节点或分片，确认副本接管和客户端拓扑刷新。
注入延迟与部分丢包，检查灰色故障是否被真实 SLI 发现。
隔离一个可用区，测量剩余容量、缓存回源和依赖配额。
让数据主节点失联，验证多数派、fencing、选主和结果未知处理。
关闭配置、发现或扩容控制面，确认数据面继续使用有效快照。
在故障转移同时制造流量峰值，验证限流和能力阶梯。
恢复旧节点，确认旧 epoch 无法写入，并按顺序重新加入。

每次演练都应有稳态指标、预期故障范围、停止条件和恢复脚本。直接在生产拔掉整个可用区而没有爆炸半径控制，不叫成熟的混沌工程。先验证单实例、单分片和影子流量，再扩大范围。

观测要从入口一直到数据确认点

组件健康绿灯不能代替业务 SLI。至少观察：入口成功率与 P99、每可用区流量、健康实例数与安全容量、探针状态变化、连接建立速率、选主 epoch、复制 lag、结果未知数量、各降级等级占比，以及业务对账差异。

报警也要区分症状与原因。用户成功率下降是症状，应最高优先级响应；某副本离开同步集合是原因信号，若仍有足够副本和容量，可以先由自动化处理。对每个内部指标都立刻呼叫人工，值班人员会被噪声淹没。

十三、常见的伪高可用

“三个实例”可能在同一宿主机；“跨可用区”可能共享单区数据库；“自动扩容”可能在事故时拿不到节点；“健康检查通过”可能只检查 /ping；“主备切换成功”可能允许旧主继续写；“三副本”可能返回成功时只写了一份；“自动重试”可能把故障流量放大十倍；“可降级”可能用旧余额伪造成功。

另一类问题是高可用组件自身成为强依赖。集中式限流、服务发现、配置、证书、DNS 和监控都可能位于请求路径或恢复路径。对每一个组件都要问：它不可用时，已有数据面能维持多久；默认是继续、拒绝还是使用快照；恢复后怎样处理期间错过的更新。

高可用也不意味着所有东西都自动切。金额、权限和唯一写主在证据不足时宁可进入只读或处理中；推荐、通知与报表则可以丢弃、延迟或返回较弱结果。自动化边界应由业务风险决定。

十四、设计检查清单

每项 SLO 的 good event 是否同时包含正确性和延迟？
核心读、核心写与非核心能力是否分开统计可用性？
副本分布跨越了哪些物理和逻辑故障域？
是否存在共享数据库、配置、网络出口、账号或版本故障域？
失去一个实例、节点或可用区后，整条链路的安全容量是多少？
恢复是否依赖事故时临时扩容、下载配置或申请权限？
startup、readiness、liveness 与业务探针各自判断什么？
探针阈值如何平衡检测时间与误摘除，灰色故障由谁发现？
有状态切换前怎样 fence 旧主，新 epoch 在哪里校验？
候选副本需要达到什么日志或提交位置才能提升？
返回成功前数据写到几份，无法满足时选择拒绝还是降低确认级别？
客户端怎样刷新地址、关闭旧连接，并处理结果未知的写入？
缓存预热、连接风暴、消息积压和重试洪峰怎样限速？
系统有哪些能力等级，每一级允许返回哪些结果？
权限、资金、库存与普通展示数据分别 fail open 还是 fail closed？
发布是否按故障域分批，schema 是否允许新旧版本共存？
故障注入是否覆盖单实例、单区、灰色网络、主节点和控制面？
旧节点恢复后是否默认无写权限，怎样安全重新加入？

结语

高可用由一条完整的接管路径组成：副本跨越真实故障域，探针判断当前能力，仲裁者授予唯一写权限，剩余系统拥有足够容量，客户端刷新路由，业务在切换窗口进入事先批准的能力等级。

多部署一台机器通常只是成本的一部分。确定数据确认点、隔离旧主、准备故障容量和反复演练，才会持续占用工程投入。把这些条件写成可观测的状态与验收指标后，自动故障转移才有明确的安全边界；证据不足时退到只读、排队中或明确失败，也比快速返回一个无法证明正确的成功结果更可用。