高可用与容错

容错领域有一条贯穿全章的反直觉主线：很多在单机时代用来"提高可靠性"的本能动作，放到分布式系统里会反过来制造故障。遇错就重试、超时就拉长、依赖慢了就多开线程顶上——这些在单机里无害的反应，在多机协作下会把一次局部抖动放大成全局崩溃。本章逐个机制拆开它们为什么会失控、正确的版本长什么样、代价是什么。

把第 01 章那把尺子拿过来回扣一下：无状态层的容错相对简单——副本可互换，挂一个换一个即可。真正棘手的容错全集中在有状态层：谁是主、数据是否还在多数派手里、分区两侧会不会都自认为是主。所以本章后半段（脑裂 + fencing）才是有状态系统最硬的容错问题，它直接接上第 04 章留下的"脑裂的完整防御在 08 章"那个伏笔。

8.1冗余与故障检测：恢复速度由检测决定

跑多个副本只是必要条件；系统多快恢复，取决于多快确信某个副本已经死了——而"确信"本身在分布式里是个无解的难题。

高可用的第一直觉是冗余：跑 N 个副本，挂一个还有 N-1 个。这没错，但它只回答了"故障发生后还有没有备件"，没回答更关键的问题——系统多久才知道要切换。一个典型的故障转移（failover）链路是：故障检测器持续探活（heartbeat / health check）→ 判定某副本已死 → 控制器把流量切到健康副本。这条链路里，副本数量决定切到哪，但检测延迟决定多久才切。一个有 5 个副本、却要 30 秒才判定主节点死亡的系统，恢复时间是 30 秒；一个只有 2 个副本、200 毫秒就检测到的系统，恢复时间是 200 毫秒。冗余多寡在这里几乎不影响恢复速度。

固定超时的两难，与 phi 累积检测器

最朴素的检测是固定超时：超过 T 毫秒没收到心跳就判死。问题是 T 是个写死的常数，而真实网络的延迟会波动——午高峰 GC、跨机房抖动都会让心跳偶尔迟到。固定 T 要么为了不误判而设得很大（恢复慢），要么为了快恢复而设得很小（频繁误判）。

phi 累积故障检测器（phi accrual failure detector）换了个思路：不输出"死/活"这个布尔值，而是输出一个连续的怀疑度。它持续记录心跳到达的间隔，拟合成一个正态分布；当前这次心跳"迟到"了多久，就换算成一个概率 P（在历史分布下，间隔超过当前等待时长的概率），再取 phi = -log10(P)。phi 越大代表越可疑。调用方自己定阈值（如 phi > 8 才判死）。它的好处是自适应：网络整体变慢时，历史分布的方差变大，同样的迟到换算出的 phi 反而变小——阈值自动放宽，误判减少。Cassandra 和 Akka 用的就是这套。

• 代价：要维护每个节点的心跳间隔历史窗口（额外内存与计算），且冷启动时样本不足、估计不准。
• 何时失效：当延迟分布根本不是正态（如双峰：要么 1ms 要么 1s），正态拟合给出的概率会偏，phi 失真。

8.2熔断器：保护的是调用方，不是下游

熔断器（circuit breaker）真正的价值不是"检测到下游故障"，而是在下游变慢时立刻停止向它发请求，把调用方自己被占用的线程和连接腾出来。

最危险的下游故障不是"死了"，而是"慢了但没死"。一个死掉的依赖会立刻拒绝连接，调用方很快得到错误、释放线程。但一个慢依赖会让每个调用方线程都挂在那里等响应——等到超时为止。在高 QPS 下，线程池会被这些"挂着等"的请求迅速占满，于是调用方自己也无法服务任何请求，哪怕它本身完全健康。慢依赖通过耗尽调用方资源，把故障传染给了上游。这就是级联失败的核心传播路径。

熔断器是一个三态状态机，挡在调用方和下游之间：

三态的运行逻辑：

• CLOSED（闭合）：正常放行所有请求，同时在滑动窗口里统计错误率/慢调用率。一旦超过阈值，跳到 OPEN。
• OPEN（打开）：直接本地快速失败，请求根本不发给下游。这一步腾出了调用方的线程与连接——这是熔断的全部意义所在。停留一个冷却期。
• HALF-OPEN（半开）：冷却到期后，放少量探针请求试探下游是否恢复。探针成功→回 CLOSED；探针失败→退回 OPEN 再冷却。

代价与失效场景：熔断打开期间，所有请求快速失败，这对下游是"放弃"而非"挽救"——必须配降级（fallback：返回缓存值、默认值或友好错误）才不会把熔断变成对用户的全量报错。阈值设太敏感会在下游正常抖动时误熔断（可用性反降）；窗口设太长则恢复迟钝。熔断器是进程内的，它保护不了"下游已经被打垮"这件事本身——那需要下游侧的限流（8.3）。

8.3限流：四种算法与它们各自漏掉的东西

限流（rate limiting）是在被保护资源的入口设闸：超过承载能力的请求宁可早早拒绝（返回 429/503），也不让它进来把系统拖垮。早拒绝是止血，晚崩溃是失血。

限流和熔断分工不同：熔断是调用方保护自己不被下游拖垮，限流是被调用方保护自己不被调用方打爆。四种主流算法，各有各的取舍：

选型逻辑：真实流量天然有突发，所以多数 API 网关默认令牌桶——它在限定平均速率的同时容许短促尖峰。需要严格平滑输出（如对一个脆弱的下游匀速喂请求）才用漏桶。需要精确到每个请求时间但 QPS 不高，用滑动窗口日志；高 QPS 想又快又基本准，用滑动窗口计数。

8.4重试风暴：退避、抖动与幂等，缺一不可

重试在偶发抖动下能救命，在系统性过载下会致命——区别在于重试是否配齐了三件套：退避拉开间隔、抖动打散同步、幂等令牌保证重复安全。

重试是最容易被滥用的容错手段，因为它在单机和低负载下几乎总是"对"的。它在两个场景里会变成纵火犯：

重试风暴：跨层放大

当下游因过载而开始失败，每一层都重试，重试次数会沿调用链相乘放大。这是退避之外更隐蔽的危险：

正确的重试 = 退避 + 抖动 + 幂等

三件套缺一不可，每一件堵一个独立的失败模式：

• 指数退避（exponential backoff）：每次重试间隔翻倍（如 1s、2s、4s），给下游喘息时间，避免失败后立刻贴脸重发。但光有退避不够——它解决"太快"，没解决"太齐"。
• 抖动（jitter，随机化）：纯指数退避有个隐患——大量客户端在同一时刻一起失败，会算出同一个退避时间，于是又在同一时刻一起重试（thundering herd，惊群）。full jitter 把退避改成在 [0, cap] 区间均匀随机取值，把这群同步的重试摊开到时间轴上。这里随机性让系统更健壮，是反直觉的——在重试调度上，确定性才是缺陷。
• 幂等令牌（idempotency token）：重试意味着同一个操作可能执行多次。只有当操作带幂等键、服务端能识别"这是重复请求"并返回首次结果时，重试才是安全的。否则重试一笔"扣款"就是重复扣款。

8.5超时预算与舱壁：给故障划定边界

超时预算（deadline）让请求永远不会无限期挂住线程；舱壁（bulkhead）把不同依赖的资源隔开，让一个依赖被打满时只饿死自己那一格，不拖垮整条船。

超时预算沿调用链传播

单点超时（每个调用各设一个固定 timeout）有个问题：它们不协调。一个用户请求穿过 5 个服务，如果每层各设 3 秒超时，最坏情况用户要等 15 秒——而用户可能 2 秒就已经放弃刷新了，后面这 13 秒的工作全是浪费，还白白占着每一层的线程。

超时预算（deadline propagation）把"剩余可用时间"作为一个值随请求往下传。入口设定总预算（如 2 秒），每经过一跳就减去已耗时间，把剩余预算传给下一跳。某一跳发现剩余预算已不够完成自己的工作，就立刻放弃、不再往下发——因为即便做完，上游也早已超时丢弃了结果。这保证了：没有任何一个请求会占用线程超过它的全局预算，慢请求被及时砍掉，线程被回收。gRPC 的 deadline、很多 RPC 框架的 timeout 透传就是这个机制。

舱壁：隔离资源，限制故障爆炸半径

舱壁这个词来自船体设计——船舱被隔板分成多个互不连通的水密舱，一个破洞进水只淹一个舱，船不沉。在系统里，舱壁指给每个下游依赖分配独立的资源池（独立线程池或独立连接池），而不是所有依赖共用一个大池子。

舱壁有两种实现：

• 线程池隔离：每个依赖一个独立线程池，调用在该池的线程上执行。隔离最彻底（连慢调用都被关在自己的线程里），但线程切换有开销，线程数多时成本高。这是 Hystrix 的经典模型。
• 信号量隔离：用一个计数器限制某依赖的并发数，调用在调用方线程上直接执行。开销小，但因为不另起线程，挡不住调用方线程本身被慢调用挂住——它只限并发数，不做线程隔离。适合本身极快的本地调用。

超时、熔断、舱壁、降级是配套使用的一套止血组合：超时保证单个请求不会无限挂住，熔断保证大面积失败时不再徒劳发请求，舱壁保证一个依赖的故障不外溢，降级保证用户拿到一个兜底响应而非报错。第 07 章的缓存击穿和雪崩在这里接上——缓存层崩溃造成回源洪峰时，正是靠这套组合（熔断回源 + 限流 + 降级返回旧值）止血。

8.6脑裂与 fencing token：带 TTL 的锁本身不安全

网络分区会让两个节点都自认是主、都接受写，造成数据损坏（脑裂）。正确防御是多数派选主 + fencing token；任何基于"锁有 TTL 就安全"的方案都会在进程暂停时破功。

这是本章最硬、也是有状态系统最致命的容错问题，它直接接续第 04 章。脑裂（split-brain）的成因：网络分区把集群切成两半，每半都收不到对方心跳，于是两半各自选出/认定一个主，两个主都开始接受写入。等分区恢复，两份分叉的数据无法合并，数据已损坏。8.1 节那个 GC 暂停的例子是脑裂的另一条触发路径——主没死只是停顿，备却已升主。

第一层防御：多数派才能当主

第一道闸是多数派（quorum）：规定只有拿到 ⌊N/2⌋+1 票的节点才能成为主。这直接调用了第 05 章的多数派 overlap——任意两个多数派必然相交，所以不可能同时存在两个都被多数派认可的主。被分区切到少数派一侧的节点凑不齐多数票，只能停摆（拒绝服务），而不是自立为主。这把"两个主都活跃"挡掉了大半。

第二层防御：fencing token，因为多数派也不够

但多数派挡不住一种情况：一个曾经合法的主，在被取代后仍以为自己是主（GC 暂停、长 STW、VM 被挂起后恢复）。它手里可能还攥着一个"看起来有效"的锁或租约，于是带着陈旧身份去写存储。这时需要第二层——fencing token（栅栏令牌）。

机制：每次有节点获得 leadership/锁，协调者发给它一个单调递增的令牌号（1, 2, 3…）。节点每次写存储都必须带上自己的令牌号。存储端记住它见过的最大令牌号，主动拒绝任何令牌号更小的写。这样，旧主即使复活、即使还攥着旧锁，它的令牌号（比如 33）已经小于新主的令牌号（34），存储端会直接拒绝它的写——栅栏把陈旧的持锁者挡在数据之外。

8.7混沌工程：在受控条件下逼出潜伏的故障

混沌工程（chaos engineering）不是"随机搞破坏"，而是一套科学方法：先定义可测的稳态假设，再从最小爆炸半径注入故障，验证假设是否仍成立——把故障切换和降级逻辑里的潜伏 bug，在白天受控地暴露出来，而不是在凌晨三点被它们叫醒。

前面六节讲的所有机制——熔断、退避、舱壁、fencing——都有一个共同的残酷事实：它们只在真正发生故障时才会被执行，而那恰恰是最不该出错的时刻。一段从没被触发过的故障转移代码，等同于一段没测过的代码；它很可能在第一次真实故障时才暴露 bug，而那时整个系统正在燃烧。混沌工程的存在就是为了反转这个时序：主动、可控地制造故障，让这些路径在可观测、可回滚的条件下先跑一遍。

它的方法论有四步，关键在于不是乱来：

• 定义稳态假设：用可测量的指标描述"系统正常"是什么样（如"下单成功率 ≥ 99.5%、p99 延迟 < 800ms"）。没有可测稳态，注入故障后无从判断有没有出问题。
• 最小爆炸半径起步：从影响最小的范围开始（单个实例、单个可用区的一小部分流量），而不是上来就拔整个机房。爆炸半径可控是混沌工程区别于"作死"的根本。
• 注入真实故障：杀进程、注入延迟、丢包、模拟依赖超时——复现生产里真会发生的故障类型。
• 验证假设是否仍成立：注入后，稳态指标是否还在阈值内？如果熔断/降级生效，用户应几乎无感；如果指标崩了，就找到了一个潜伏 bug——这正是实验的目的。

8.8失败模式清单与多层防御

本章的机制各自针对特定失败模式。把它们汇成一张对照表，便于在评审里快速定位"这个故障该用哪些防御组合"。多数严重故障需要多层叠加，单一机制挡不住：