【分布式系统百科】故障的分类学：从 fail-stop 到 Byzantine

本文属于分布式系统百科系列。上一篇 FLP、CAP 与不可能性结果 讨论了分布式系统的理论边界；本文聚焦于故障模型——系统设计的第一个选择，也是最影响全局的选择。

你的 Raft 集群跑了三个月，一切正常。某天凌晨三点，监控告警：leader 切换了五次，但没有节点挂掉。日志显示所有节点都在正常发送心跳。查了半小时，发现其中一个节点的磁盘 I/O 延迟从平均 0.5ms 飙升到 200ms。心跳发得出去，但日志持久化太慢，导致这个节点作为 leader 时无法及时 commit，follower 超时触发选举，新 leader 上来又碰到同样的问题——因为三个节点里有两个的磁盘都是同一批次的，I/O 延迟都在恶化。

这个节点没有崩溃（crash-stop 模型管不了它），也没有发送错误数据（Byzantine 模型杀鸡用牛刀），它只是”变慢了”。但”变慢”足以让你的共识协议反复抖动，服务不可用。

教科书把故障分成两类：crash 和 Byzantine。这个分类在理论推导时足够用，但在生产环境里远远不够。真实系统面对的故障谱系要复杂得多：网卡偶尔丢包但不断连、磁盘静默地翻转几个 bit、NTP 服务挂了导致时钟偏移越来越大、GC 停顿让进程”假死”几秒。这些故障不属于 crash，也不完全是 Byzantine，但它们能让你精心设计的容错算法做出错误决策。

这篇文章做三件事：

1. 建立一个完整的故障层级模型，把 crash-stop、crash-recovery、omission、performance、Byzantine 五层故障的包含关系讲清楚。
2. 用真实事故案例说明每种故障在生产中的表现。
3. 拆解故障检测（Failure Detection）的核心算法，包括 phi Accrual Failure Detector 的完整 Go 实现。

一、故障层级模型

分布式系统理论里，故障模型（Failure Model）定义了”系统中的组件可能出什么错”。故障模型的选择直接决定了算法的复杂度和成本：假设的故障越强，容错算法就越复杂、需要的副本就越多。

Cristian 在 1991 年的论文 “Understanding Fault-Tolerant Distributed Systems” 中给出了一个经典的故障分类层级。这个层级是包含关系——外层故障类型包含内层的所有故障行为，加上自己特有的故障行为。

Crash-Stop：崩溃即永别

崩溃停止（Crash-Stop）是最简单的故障模型。一个节点要么正确运行，要么永久停止。没有中间状态。停止后不会恢复，不会发送错误消息，不会做任何事。

几乎所有经典共识算法的原始证明都基于这个模型。Lamport 的 Paxos（1998）和 Ongaro-Ousterhout 的 Raft（2014）在安全性证明中都假设 crash-stop。在这个模型下，容忍 f 个故障需要 2f+1 个节点：5 个节点容忍 2 个崩溃，3 个节点容忍 1 个。

形式化定义：进程 p 表现为 crash-stop 故障，当且仅当存在时刻 t 使得：（1）对于所有 t’ < t，p 严格按照其规约正确执行；（2）对于所有 t’ >= t，p 不再执行任何步骤、不发送任何消息、也不接收任何消息。该模型的关键性质在于：crash-stop 故障在原理上是可检测的——在同步系统中，超时后未收到消息即可推断进程已崩溃。

这个模型的核心特征：节点在崩溃前的所有行为都是正确的。不存在”半崩溃”的状态——不会出现节点发了一半消息就停了的情况。严格来说，crash-stop 假设节点的崩溃对外部是可检测的（至少最终可检测），这一点在异步系统中其实做不到（参见 FLP 不可能性），但作为理论起点仍然有用。

现实中的 crash-stop：进程被 OOM Killer 杀掉、硬件断电、内核 panic。这些场景确实接近 crash-stop，前提是崩溃后不自动重启。

Crash-Recovery：崩溃了还会回来

崩溃恢复（Crash-Recovery）模型放宽了一个限制：节点崩溃后可以重启。重启后，节点的易失性状态（Volatile State）丢失，但持久化状态（Stable Storage，比如写到磁盘上的 WAL）保留。

形式化定义：进程 p 表现为 crash-recovery 故障，当 p 可能在正确执行期与崩溃期之间交替切换。崩溃期间，p 停止执行一切操作。恢复时，p 仅保留存储在稳定存储（stable storage）中的状态，所有易失性状态丢失。形式化地：在恢复时刻 t_r，p 的状态被重置为 s_stable(t_r)，其中 s_stable 是最近一次崩溃前最后一次成功持久化的状态。

这个区别对算法设计的影响很大。在 crash-stop 模型中，一个节点投了票之后崩溃，你可以认为这张票”永远有效”——反正它不会再做任何事。但在 crash-recovery 模型中，节点重启后可能忘记自己投过票（如果投票记录没有持久化），然后给另一个 candidate 再投一票。两张票就可能导致两个 leader 同时存在，破坏安全性。

所以 Raft 要求每个节点在回复 RequestVote 之前，必须先把 votedFor 和 currentTerm 持久化到稳定存储。etcd 的实现中，这个持久化发生在 HardState 结构体的写入中：

// etcd/raft/raft.go 中的关键持久化字段
// HardState 在每次状态变更时持久化到 WAL
type HardState struct {
    Term   uint64
    Vote   uint64
    Commit uint64
}

crash-recovery 模型比 crash-stop 复杂，但对副本数的要求没有增加（仍然是 2f+1），前提是持久化机制可靠。问题就在这个”前提”上——磁盘本身可能出错，这就进入了更高层级的故障模型。

Omission：消息丢了

遗漏故障（Omission Failure）指节点本身还在运行，但无法正确发送或接收消息。根据方向不同，分为两种：

• 发送遗漏（Send Omission）：节点执行了发送操作，但消息没有到达目标。可能是发送缓冲区满了，可能是网卡驱动丢包。
• 接收遗漏（Receive Omission）：消息到达了节点的网络接口，但应用层没有收到。可能是接收缓冲区溢出，可能是内核把包丢了。

网络分区（Network Partition）是遗漏故障的一种系统性表现：两组节点之间的所有消息都被丢弃。

遗漏故障和 crash 的关键区别是：节点仍然在运行，可能还在处理本地请求，只是通信出了问题。如果一个 Raft follower 因为网络分区收不到 leader 的心跳，它会认为 leader 挂了，发起选举——但实际上 leader 活得好好的。这就是所谓的”脑裂”（Split-Brain）场景。

Bailis 和 Kingsbury 在 2014 年的综述 “Network Partitions in Practice” 中收集了大量生产环境的分区事件数据。他们的结论是：网络分区在现代数据中心中并不罕见，即使是同一机房内的网络也会出现短暂分区。这篇综述直接反驳了”分区在现代网络中可以忽略”的观点，也是理解 CAP 定理实际影响的重要参考。

Performance：正确但太慢

性能故障（Performance Failure），也叫时序故障（Timing Failure），指节点的响应在内容上是正确的，但没有在规定时间内到达。

在同步系统模型（Synchronous Model）中，消息传递有一个已知的上界 delta。如果消息在 delta 时间内没到，就可以判定为故障。但在异步系统模型（Asynchronous Model）中，没有这个上界——你永远无法区分”对方很慢”和”对方挂了”。

性能故障是生产环境中最常见也最难处理的故障类型。几个典型场景：

灰色故障：最难的那种

Huang 等人在 2017 年的论文 “Gray Failure: The Achilles’ Heel of Cloud-Scale Systems” 中提出了灰色故障（Gray Failure）的概念。灰色故障的定义是：系统组件的故障状态对不同观察者呈现不同的表现。一个典型的例子：

• 从节点 A 的视角看，节点 C 能正常响应心跳。
• 从节点 B 的视角看，节点 C 完全不可达。
• 从节点 C 自身的视角看，它一切正常。

灰色故障之所以难处理，是因为传统的故障检测机制依赖”多数节点对某个节点的状态达成一致”。但灰色故障恰恰制造了不一致的观察。

另一种灰色故障表现是性能退化但未彻底停止。节点还在响应，但延迟从 1ms 变成了 500ms。如果你的心跳超时设成 1s，这个节点看起来”正常”。但如果它是 leader，客户端请求的延迟已经不可接受了。

灰色故障不是理论假设。Huang 等人在论文中分析了多个真实案例，包括 Azure 存储服务的故障事件，表明灰色故障是大规模云系统中最常见的故障模式之一。

灰色故障与拜占庭行为的生产识别

灰色故障最棘手的特征在于：发生故障的节点自身的健康检查往往显示一切正常。故障对外部请求者可见，但对节点自身不可见。因此，检测灰色故障必须依赖外部观察和横向对比，而非节点自身的上报。以下是生产环境中识别灰色故障和类拜占庭行为的关键手段：

差异化指标监控（Differential Metrics Monitoring）：对同一角色的对等节点采集相同指标，进行横向对比。如果节点 C 的 P99 延迟比节点 A 和 B 高出 10 倍，即使节点 C 的健康检查全部通过，它也是灰色故障的候选者。关键在于不看绝对值，而看同类节点之间的相对偏差。

金丝雀探测（Canary Checks / Synthetic Probes）：主动向目标节点发送已知正确的请求，并验证返回结果是否符合预期。如果返回结果错误或延迟异常偏高，该节点存在灰色或拜占庭问题，即使它在常规健康检查中报告自己为”健康”。合成探测是检测静默数据损坏类故障的有效手段。

影子流量对比（Shadow Traffic Comparison）：将生产流量的副本同时路由到被怀疑的节点和一个已知正常的节点，对比两者的响应。响应不一致即表明存在拜占庭式行为。这种方法在不影响线上服务的前提下提供了高置信度的故障判定。

多观察者共识（Multi-Observer Consensus）：不依赖单一观察者的判断。从多个对等节点聚合健康信号——这本质上就是 SWIM 协议的间接探测机制。如果 5 个观察者中有 3 个报告节点 C 响应缓慢，则应采信多数意见。单一视角的健康判断在灰色故障面前毫无意义。

全链路校验和（Checksums at Every Boundary）：在数据的读写路径上，每个组件边界都加入端到端校验和。静默数据损坏（silent data corruption）不会触发任何健康检查告警，只有校验和能捕获它。从应用层写入到存储引擎落盘，再到读取返回，每一跳都应校验数据完整性。

核心洞察：灰色故障对自身健康检查不可见。一个正在经历灰色故障的节点会报告自己为健康状态。检测必须是外部的、比较性的。

graph TD
    subgraph 观察者视角
        A["观察者 A：认为 C 健康"]
        B["观察者 B：认为 C 不健康"]
    end
    subgraph 目标节点
        C["节点 C：自我报告健康"]
    end
    A -->|"ping 正常"| C
    B -->|"请求超时"| C
    C -->|"健康检查通过"| C
    A --> V{"多观察者投票"}
    B --> V
    C --> V
    V -->|"观察不一致"| GF["判定：灰色故障"]

上图展示了灰色故障检测的多观察者投票机制。节点 C 的自我健康检查始终通过，但观察者 A 和 B 对 C 的可达性判断不一致。通过聚合多个观察者的信号并检测不一致，系统能够识别出单一视角无法发现的灰色故障。这正是为什么分布式故障检测协议（如 SWIM）采用间接探测的根本原因。

Byzantine：什么错都可能犯

拜占庭故障（Byzantine Failure）是最强的故障模型。一个拜占庭节点可以做任何事：发送错误消息、对不同节点发送不同的消息、伪装成正常节点、故意延迟响应、选择性地丢弃消息。

Lamport、Shostak 和 Pease 在 1982 年的经典论文 “The Byzantine Generals Problem” 中证明了：在存在 f 个拜占庭节点的系统中，至少需要 3f+1 个节点才能达成一致。这个成本比 crash-stop 的 2f+1 高出一个量级。

为什么是 3f+1？直觉上的解释是：拜占庭节点可以对不同节点说不同的话。你需要足够多的正确节点来”交叉验证”。3f+1 个节点中，去掉 f 个拜占庭节点还剩 2f+1 个正确节点，其中 f+1 个构成多数，即使另外 f 个正确节点被拜占庭节点误导，f+1 个节点的一致意见仍然能压过去。

拜占庭容错在区块链领域得到了广泛应用（公链本质上假设存在恶意节点），但在传统分布式系统中很少使用。原因很简单：成本太高。多数数据中心场景下，节点是你自己控制的，不会故意作恶。

但这里有一个微妙的问题：非恶意的 Byzantine 行为在生产中并不罕见。内存 bit flip 导致的数据损坏、网卡硬件 bug 导致的 checksum 通过但数据错误、磁盘固件 bug 导致的静默写入错误——这些都是”节点发送了错误数据但自己不知道”的场景，从效果上看和拜占庭行为没有区别。

层级的包含关系

理解这个层级最重要的一点是包含关系：

Crash-Stop 包含于 Crash-Recovery 包含于 Omission 包含于 Performance 包含于 Byzantine。

这意味着：

• 一个能容忍 Byzantine 故障的算法，自动能容忍所有更低级别的故障。
• 一个只针对 Crash-Stop 设计的算法，碰到 Omission 或 Performance 故障时可能会出问题。

这也解释了为什么 Raft 集群在磁盘变慢时会反复切主——Raft 针对 crash-stop/crash-recovery 设计，性能故障不在它的容错范围内。Raft 的安全性（Safety）不受影响（不会选出两个 leader、不会丢已提交的数据），但活性（Liveness）会受损（集群可能长时间无法提交新日志）。

二、真实故障案例分析

理论模型讲完了。接下来看这些故障在生产环境中长什么样。

AWS us-east-1 EBS 故障（2011）

2011 年 4 月 21 日，AWS 的 us-east-1 区域发生了大规模 EBS（Elastic Block Store）故障，持续约 48 小时，影响了大量依赖 EBS 的 EC2 实例和 RDS 数据库。

根因：一次网络变更操作将一个 EBS 集群的流量错误地路由到了一个低带宽的链路上。流量涌入导致该链路拥塞，EBS 节点之间的数据复制（re-mirroring）流量开始竞争带宽。

级联过程：

1. 网络变更导致部分 EBS 节点之间的连接中断。
2. EBS 的副本机制检测到”副本不足”，触发 re-mirroring，在集群内大规模复制数据。
3. re-mirroring 的流量进一步加剧了网络拥塞，导致更多节点被隔离。
4. 更多节点被隔离 → 更多 re-mirroring → 更多拥塞。正反馈循环。
5. EBS 控制面因为需要处理大量状态变更也开始过载。

从故障模型的角度看，这个事件的触发点是遗漏故障（网络链路拥塞导致丢包），但它迅速演变成了一系列性能故障（re-mirroring 导致整个集群变慢），并且由于级联效应，最终导致大量节点实际不可用。

这个案例的教训是：真实系统的故障很少停留在单一层级。一个 Omission 故障（网络丢包）可以通过系统内部的反馈机制升级为全局性的 Performance 故障乃至部分节点的 Crash。

AWS 在事后复盘报告（Post-Mortem Summary of the Amazon EC2 and Amazon RDS Service Disruption, 2011）中承认了这个级联效应，并描述了后续的改进措施，包括限制 re-mirroring 的速率和隔离控制面流量。

Cloudflare 内存安全 Bug（2017）

2017 年 2 月，Cloudflare 披露了一个被称为 “Cloudbleed” 的安全事件。他们的 HTTP 代理使用的一个 HTML 解析器（基于 Ragel 状态机编译器生成的代码）存在缓冲区越界读取的 bug。当解析器处理某些格式错误的 HTML 标签时，会读取并返回相邻内存中的数据——可能包含其他请求的 HTTP header、cookie、甚至 POST body。

从故障分类的角度看，这是一个非恶意的 Byzantine 行为：节点（Cloudflare 边缘服务器）发送了错误的数据给客户端，但节点本身不知道自己发了错误数据。服务器的所有自我检查（健康检查、进程存活性）都显示正常。bug 只有在特定输入组合下才触发。

这类故障用 crash-stop 或 omission 模型完全解释不了。节点没有崩溃，也没有丢消息。它在正常通信，只是通信的内容是错的。

Cloudflare 在官方博客 “Incident report on memory leak caused by Cloudflare parser bug” (2017-02-23) 中详细描述了根因和修复过程。核心问题是 C 语言的内存安全缺陷——换成内存安全的语言（Rust、Go）可以从根本上避免这类缓冲区越界。

CockroachDB 时钟偏移问题

CockroachDB 使用混合逻辑时钟（HLC）来排序事务。HLC 依赖物理时钟作为基础，逻辑计数器处理同一物理时间内的事件排序。但 HLC 有一个前提：参与集群的各节点之间的物理时钟偏移不能超过一个已知的上界（CockroachDB 默认设置为 500ms）。

如果时钟偏移超过这个上界，CockroachDB 的事务可能观察到不一致的快照。具体来说：一个节点上的写入事务可能获得一个”过大”的时间戳，导致另一个节点上的读事务看不到这个写入（即使写入在因果上先于读取）。

CockroachDB 通过以下机制检测和应对时钟偏移：

1. 节点之间在 RPC 通信时交换时间戳，检测偏移量。
2. 如果检测到偏移超过上界的一半（默认 250ms），记录警告日志。
3. 如果检测到偏移超过上界（默认 500ms），节点会主动拒绝处理请求并建议运维人员修复 NTP 配置。

从故障模型看，时钟偏移属于性能故障（Timing Failure）的范畴：节点的行为在逻辑上正确（按照自己的时钟做了正确的事），但在全局视角下时序关系被破坏了。

CockroachDB 官方文档 “Clock Synchronization” 部分对此有详细说明。核心观点是：CockroachDB 不要求完美的时钟同步，但要求时钟偏移有界。这是一个比纯异步模型更强、但比 Google TrueTime 更弱的假设。

磁盘静默数据损坏

Google 的 Bairavasundaram 等人在 2007 年的论文 “An Analysis of Latent Sector Errors in Disk Drives” 和 2008 年的论文 “An Analysis of Data Corruption in the Storage Stack” 中，基于大量生产环境磁盘的数据，分析了磁盘静默数据损坏（Silent Data Corruption）的频率。

几个关键数据点：

• 在观察的 150 万块磁盘中，约 3.45% 的 SATA 磁盘和 1.9% 的 FC 磁盘在 32 个月的观察期内发生了至少一次潜在扇区错误（Latent Sector Error）。
• 每 1 万块磁盘中，大约有 1 块在一年内会发生静默数据损坏——磁盘报告写入成功，但读出来的数据与写入的不一致，且磁盘的内部 ECC 没有检测到错误。

静默数据损坏是一种纯粹的 Byzantine 行为：磁盘告诉操作系统”写入成功了”，但数据实际上是错的。操作系统、文件系统、应用层——如果没有额外的校验机制，没有任何一层会发现问题。

ZFS 用 Merkle 树结构对每个数据块做校验，发现损坏后可以从镜像或 RAID-Z 中恢复。ext4 从 Linux 4.12 开始支持 metadata checksum，但默认不校验数据块内容。etcd 使用 BoltDB，BoltDB 本身不做数据校验——如果底层磁盘静默地翻转了几个 bit，BoltDB 不会发现，直到应用层读到了一个反序列化失败的值。

这就是为什么仅仅在共识层做 crash-recovery 容错是不够的。你的 WAL 写成功了，fsync 返回了，操作系统说数据落盘了——但数据可能已经坏了。

网络分区的频率

“网络分区是理论问题，在现代数据中心里基本不会发生”——这个说法在 2010 年代早期很常见。Bailis 和 Kingsbury 在 2014 年的论文 “Network Partitions in Practice: Do They Exist? Is There Anything to Do?” 中系统性地反驳了这个观点。

他们收集了来自多个大型系统的分区事件报告，结论包括：

• 网络分区在生产环境中确实发生，包括同一数据中心内部。
• 分区的原因多种多样：路由器 bug、交换机固件升级、光缆施工意外切断、配置变更错误、DNS 故障。
• 分区的持续时间从秒级到小时级不等。
• 即使使用冗余网络拓扑，分区仍然可能发生——因为配置变更可能同时影响主备链路。

这篇综述论文引用了多个一手事故报告，包括前面提到的 AWS 2011 事件。它的核心论点是：分区不是理论假设，而是工程现实，任何声称”可以忽略分区”的系统设计都在冒险。

从故障模型的角度看，网络分区是一种系统性的遗漏故障——两组节点之间的所有消息都被丢弃。但分区经常不是完全的：可能只是部分节点之间不通（部分分区），可能只是某个方向不通（非对称分区），也可能只是延迟增大到不可接受（性能退化而非完全丢包）。

三、故障检测

故障检测（Failure Detection）是分布式系统的基础设施之一。共识算法、leader 选举、成员管理——几乎所有分布式协议都依赖某种形式的故障检测。

心跳与超时：简单但脆弱

最直接的故障检测方式：节点 A 定期给节点 B 发心跳（Heartbeat），如果 B 在超时时间 T 内没有收到 A 的心跳，就判定 A 故障。

这个机制有一个根本问题：超时值 T 怎么设？

• T 设太小：正常的网络抖动或 GC 停顿就会触发误报（False Positive），导致不必要的 leader 切换或节点驱逐。
• T 设太大：真正的故障需要等很长时间才能被检测到，服务长时间不可用。

在异步系统中，没有”正确”的 T 值。这就是 FLP 不可能性的实践表现：在一个没有时间上界的系统中，你无法区分”节点很慢”和”节点已死”。

工程上的常见做法是基于经验设一个值，然后祈祷。Raft 的建议是 election timeout 设为 broadcastTime 的 10 倍以上（Ongaro 和 Ousterhout 在论文中建议 broadcastTime << electionTimeout << MTBF）。etcd 默认 election timeout 是 1000ms，心跳间隔是 100ms。

但”基于经验设一个值”在环境变化时很容易失效。你的集群从物理机搬到了 Kubernetes，网络延迟特征完全变了。原来 200ms 的超时够用，现在需要 2s。如果你没有及时调整，就会看到持续的 leader 切换。

Phi Accrual Failure Detector：自适应检测

Hayashibara 等人在 2004 年的论文 “The Phi Accrual Failure Detector” 中提出了一种自适应的故障检测器。核心思想：不要输出”节点活着/死了”的二值判断，而是输出一个连续的怀疑程度（suspicion level），用 phi 值表示。

phi 值的含义：如果 phi = 1，表示判断错误的概率大约是 10%。phi = 2 对应 1%。phi = 3 对应 0.1%。对数递增。

具体计算方式：

1. 维护最近 N 次心跳的到达间隔（arrival interval）的历史窗口。
2. 用这些间隔估计到达时间的分布参数。论文中假设正态分布（Normal Distribution），用均值 mu 和标准差 sigma 来描述。
3. 当需要判断时，计算”如果节点还活着，当前时刻还没收到心跳的概率”，然后取负对数得到 phi。

公式：phi(t_now) = -log10(1 - F(t_now - t_last))

其中 F 是到达间隔的累积分布函数（CDF），t_last 是上一次收到心跳的时间。

Cassandra 使用 phi accrual failure detector 作为其默认的故障检测机制。阈值（phi_threshold）默认设为 8，对应约 10^-8 的误判概率。在网络条件变化时，检测器会自动调整——因为它基于历史数据估计分布，当延迟增大时，分布的均值和标准差也会相应增大，避免过早误判。

flowchart TD
    HB["心跳到达"] --> REC["记录到达间隔到滑动窗口"]
    REC --> CALC["计算均值 mu 和标准差 sigma"]
    CALC --> QUERY{"收到查询请求"}
    QUERY --> ELAPSED["计算距上次心跳的已过时间 elapsed"]
    ELAPSED --> CDF["计算 CDF：F(elapsed)"]
    CDF --> PHI["phi = -log10(1 - F(elapsed))"]
    PHI --> CMP{"phi > 阈值？"}
    CMP -->|"是"| SUSPECT["判定：SUSPECT"]
    CMP -->|"否"| ALIVE["判定：ALIVE"]

上图展示了 phi accrual 故障检测器的完整工作流程。每次心跳到达时，检测器将到达间隔记录到滑动窗口中，并据此估计心跳间隔的统计分布。当需要判断节点状态时，检测器根据”距上次心跳已过去多久”计算出一个连续的怀疑程度 phi 值，而非简单的”活/死”二值判断。phi 值越高，节点已故障的概率越大；与固定超时相比，这种自适应机制能在网络条件变化时自动调整灵敏度。

下面是一个完整的 Go 实现：

package phiaccrual

import (
    "math"
    "sync"
    "time"
)

// PhiAccrualDetector 实现 phi accrual 故障检测器。
// 基于 Hayashibara et al. 2004 论文。
type PhiAccrualDetector struct {
    mu        sync.Mutex
    intervals []float64 // 心跳到达间隔（毫秒）
    lastBeat  time.Time // 上一次心跳到达时间
    windowSize int      // 滑动窗口大小
}

// New 创建一个 phi accrual failure detector。
// windowSize 控制用于估计分布的历史样本数量，推荐 100-1000。
func New(windowSize int) *PhiAccrualDetector {
    if windowSize < 10 {
        windowSize = 10
    }
    return &PhiAccrualDetector{
        intervals:  make([]float64, 0, windowSize),
        windowSize: windowSize,
    }
}

// Heartbeat 记录一次心跳到达。
func (d *PhiAccrualDetector) Heartbeat() {
    d.mu.Lock()
    defer d.mu.Unlock()

    now := time.Now()
    if !d.lastBeat.IsZero() {
        interval := float64(now.Sub(d.lastBeat).Milliseconds())
        if len(d.intervals) >= d.windowSize {
            // 滑动窗口：丢弃最旧的样本
            d.intervals = d.intervals[1:]
        }
        d.intervals = append(d.intervals, interval)
    }
    d.lastBeat = now
}

// Phi 返回当前的 phi 值。
// phi 越大，节点故障的可能性越高。
// 如果还没有足够的心跳数据，返回 0。
func (d *PhiAccrualDetector) Phi() float64 {
    d.mu.Lock()
    defer d.mu.Unlock()

    if len(d.intervals) < 2 || d.lastBeat.IsZero() {
        return 0
    }

    elapsed := float64(time.Since(d.lastBeat).Milliseconds())
    mean, stddev := d.stats()

    // 避免标准差为零导致除零错误
    if stddev < 1e-6 {
        stddev = 1e-6
    }

    // 计算正态分布的 CDF 值
    // P(X <= elapsed) 其中 X ~ Normal(mean, stddev)
    cdf := normalCDF(elapsed, mean, stddev)

    // phi = -log10(1 - CDF)
    // 1 - CDF 是"如果节点还活着，间隔超过 elapsed 的概率"
    pLate := 1.0 - cdf
    if pLate < 1e-15 {
        pLate = 1e-15 // 防止 log(0)
    }
    return -math.Log10(pLate)
}

// stats 计算间隔样本的均值和标准差。
// 调用者必须持有 mu 锁。
func (d *PhiAccrualDetector) stats() (mean, stddev float64) {
    n := float64(len(d.intervals))
    if n == 0 {
        return 0, 0
    }

    sum := 0.0
    for _, v := range d.intervals {
        sum += v
    }
    mean = sum / n

    variance := 0.0
    for _, v := range d.intervals {
        diff := v - mean
        variance += diff * diff
    }
    variance /= n
    stddev = math.Sqrt(variance)
    return mean, stddev
}

// normalCDF 计算正态分布的累积分布函数值。
// 使用标准的 erf 近似。
func normalCDF(x, mean, stddev float64) float64 {
    z := (x - mean) / (stddev * math.Sqrt2)
    return 0.5 * (1.0 + math.Erf(z))
}

使用方式：

package main

import (
    "fmt"
    "time"

    "your/module/phiaccrual"
)

func main() {
    detector := phiaccrual.New(100)

    // 模拟正常心跳（每 100ms 一次）
    for i := 0; i < 20; i++ {
        detector.Heartbeat()
        time.Sleep(100 * time.Millisecond)
    }

    fmt.Printf("正常状态 phi = %.2f\n", detector.Phi())

    // 模拟节点延迟（停止心跳 500ms）
    time.Sleep(500 * time.Millisecond)
    fmt.Printf("延迟 500ms 后 phi = %.2f\n", detector.Phi())

    // 模拟节点长时间无响应
    time.Sleep(2 * time.Second)
    fmt.Printf("无响应 2.5s 后 phi = %.2f\n", detector.Phi())
}

phi accrual detector 的几个工程要点：

1. 窗口大小的选择：窗口太小，分布估计不稳定，对突发延迟敏感。窗口太大，对环境变化的适应变慢。Cassandra 默认使用 1000。
2. 分布假设：论文假设正态分布，但实际的心跳间隔分布往往是右偏的（偶尔的大延迟）。实际实现中可以考虑用指数分布或经验分布替代。Cassandra 的实现使用了指数分布。
3. 阈值设定：phi = 8 对应约 10^-8 的误判率。对于需要快速检测的场景（如 leader 选举），可以适当降低阈值（比如 phi = 3，对应约 0.1% 的误判率）。

SWIM：O(1) 消息复杂度的故障检测

传统的心跳机制是全对全（all-to-all）的：N 个节点互相发心跳，消息复杂度是 O(N^2)。在大规模集群（几百上千个节点）中，这个开销不可忽视。

Das、Gupta 和 Lampson 在 2002 年的论文 “SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol” 中提出了一种基于感染式传播（gossip）的故障检测和成员管理协议。

SWIM 的核心检测机制：

1. 每个周期，节点 A 随机选择一个节点 B，发送一个 ping 消息。
2. 如果 B 在超时时间内回复了 ack，结束。B 被认为存活。
3. 如果 B 没有回复，A 不直接判定 B 死亡。而是随机选择 k 个其他节点，请求它们帮忙探测 B（ping-req）。
4. 如果这 k 个节点中的任何一个收到了 B 的回复，A 就认为 B 存活。
5. 只有当 k 个间接探测全部失败时，A 才将 B 标记为可疑（suspected）。

通过间接探测机制，SWIM 避免了因为 A 到 B 的直接链路故障（遗漏故障）而误判 B 死亡的问题。这一点直接应对了灰色故障中”不同观察者看到不同状态”的情况。

SWIM 的消息复杂度：每个周期，每个节点发 1 个 ping + 最多 k 个 ping-req。总计 O(N) 条消息/周期，平均到每个节点是 O(1)。

HashiCorp 的 memberlist 库（Consul 和 Nomad 的成员管理组件）实现了 SWIM 协议的一个增强版本，增加了 suspicion 和 dead 状态之间的超时机制，以及基于 gossip 的状态传播。

sequenceDiagram
    participant A as 节点 A
    participant B as 节点 B
    participant C as 节点 C
    participant D as 节点 D

    A->>B: ping
    Note over B: 超时未响应
    A->>C: ping-req(B)
    A->>D: ping-req(B)
    C->>B: ping
    D->>B: ping
    B->>C: ack
    Note over D: B 未响应 D 的 ping
    C->>A: ack(B 存活)
    Note over A: 收到间接确认，标记 B 为存活

上图展示了 SWIM 协议的间接探测（indirect probe）流程。当节点 A 直接 ping 节点 B 超时后，A 不会立即判定 B 死亡，而是请求其他节点 C 和 D 代为探测。只要任一间接探测成功（如 C 收到了 B 的 ack），A 就认为 B 仍然存活。这种机制有效避免了因 A 与 B 之间的单条链路故障（遗漏故障）而产生误判，是应对灰色故障场景下”不同观察者看到不同状态”问题的核心设计。

不完美故障检测器理论

Chandra 和 Toueg 在 1996 年的论文 “Unreliable Failure Detectors for Reliable Distributed Systems” 中建立了故障检测器的理论框架。这篇论文的核心贡献是证明了：你不需要一个完美的故障检测器来解决共识问题。

论文定义了故障检测器的两个属性：

• 完整性（Completeness）：最终每个故障节点都会被某个正确节点怀疑。
• 准确性（Accuracy）：正确节点不会被怀疑（的程度）。

基于这两个属性的强弱组合，Chandra 和 Toueg 定义了八种故障检测器类别。其中最重要的是两个：

最终完美故障检测器（Eventually Perfect, diamond-P）：最终完整（every crashed process is eventually suspected by every correct process）+ 最终准确（there is a time after which no correct process is suspected）。换句话说，它可以暂时犯错（把活的节点误判为死的），但最终会纠正过来。

最终弱故障检测器（Eventually Weak, diamond-W）：最终弱完整（every crashed process is eventually suspected by some correct process）+ 最终弱准确（there is a time after which some correct process is not suspected by any correct process）。这是比 diamond-P 更弱的要求。

论文的核心定理是：diamond-W 就足以解决共识问题。这意味着，即使你的故障检测器偶尔犯错（误判活的节点为死的，或者延迟检测到故障节点），只要它”最终”能纠正，共识算法就能在这个基础上工作。

这个结论的工程意义是巨大的：它从理论上证明了”不完美的超时机制 + 超时重试”这种粗糙的故障检测方式，在原理上足以支撑共识协议的正确性（虽然会影响性能和可用性）。Raft 的 election timeout 就是一个 diamond-W 故障检测器的实例。

活性与故障检测的关系

故障检测器的不完美直接影响分布式协议的活性（Liveness），但不影响安全性（Safety）。

举个具体例子：Raft 的 leader 选举使用心跳超时作为故障检测。如果超时设得太小，follower 会频繁地误认为 leader 死了，触发不必要的选举。每次选举期间，集群无法处理新的写请求——活性受损。但选举机制本身保证了不会同时出现两个合法 leader（term 单调递增 + 日志完整性检查），所以安全性不受影响。

反过来，如果超时设得太大，leader 真的挂了之后，集群需要等很久才能检测到并选出新 leader——活性同样受损。

这个权衡没有完美解答。phi accrual detector 和 SWIM 都是在这个权衡空间里寻找更好的操作点：通过更智能的检测逻辑，在不牺牲太多检测速度的前提下降低误报率。

四、故障注入与容错测试

知道了故障类型，也知道了检测方法。接下来的问题是：你怎么知道你的系统真的能扛住这些故障？

答案是：主动制造故障，看系统的反应。

故障注入的分类

故障注入（Fault Injection）按注入的故障类型分为几大类：

这些注入手段覆盖了前面讨论的五层故障模型的各个层级。一个完整的容错测试计划应该至少覆盖 crash、omission 和 performance 三个层级。

从 Chaos Monkey 到现代混沌工程

Netflix 在 2011 年开源了 Chaos Monkey，其功能很简单：在生产环境中随机杀死虚拟机实例。目标是验证 Netflix 的微服务架构能否在节点随机崩溃的情况下保持可用。

Chaos Monkey 只注入 crash-stop 故障——随机杀进程/虚拟机。这是最简单的一种故障注入，但它建立了一个重要的实践原则：在生产环境中主动制造故障，比等故障自己发生要好。

后来的混沌工程工具扩展了注入能力：

• Chaos Monkey → 进程/虚拟机崩溃（crash-stop）
• Latency Monkey → 人工延迟注入（performance）
• Chaos Kong → 模拟整个 region 不可用（大规模 omission）

现代混沌工程框架（如 LitmusChaos、Chaos Mesh）把这些能力整合在一起，提供声明式的故障注入定义和自动化的验证流程。

混沌工程不只是”随机搞破坏”。Netflix 的 Rosenthal 等人在 “Chaos Engineering: System Resiliency in Practice” (O’Reilly, 2020) 中强调了混沌工程的科学方法论：

1. 定义系统的”稳态”——用什么指标衡量”系统正常”。
2. 提出假设——“注入故障 X 后，系统指标 Y 应该保持在范围 Z 内”。
3. 设计实验——在生产或类生产环境中注入故障。
4. 验证假设——观察实际指标是否符合预期。
5. 修复发现的问题——如果系统行为不符合预期，就修。

更深入的混沌工程实践，包括 Jepsen 测试框架（专门针对分布式数据库的线性一致性验证）和确定性模拟测试（Deterministic Simulation Testing），将在本系列后续文章 混沌工程 和 Jepsen 与正确性验证 中详细展开。

五、故障模型的工程选择

选择故障模型不是理论偏好，而是工程权衡。你假设的故障越强，系统越安全，但成本越高。

你不能假设最弱的模型

很多工程师在设计系统时隐含地假设 crash-stop 模型：节点要么正常工作，要么挂掉，没有中间状态。这个假设在以下场景中会出问题：

1. 磁盘静默损坏但不校验：crash-recovery 假设持久化状态可靠。如果磁盘损坏了一个 WAL 条目，节点重启后会读到错误数据，做出错误决策。
2. GC 停顿导致心跳超时：crash-stop 模型下，节点要么发心跳要么死了。GC 停顿让节点”暂时死了”然后”复活”，在这个期间它可能错过了 leader 切换，用旧的 leader 信息继续操作。
3. 网络部分分区：crash-stop 模型下不存在”部分可达”。但现实中 A 能和 B 通信、B 能和 C 通信、A 不能和 C 通信的情况并不罕见。

你也不需要假设最强的模型

全面使用 Byzantine 容错同样不现实：

1. 成本：3f+1 vs 2f+1，副本数多 50%。
2. 复杂度：PBFT 的消息复杂度是 O(N^2)，Raft 是 O(N)。即使 HotStuff 把 Byzantine 共识的消息复杂度降到了 O(N)，实现复杂度仍然远高于 Raft。
3. 延迟：Byzantine 容错通常需要更多轮消息交换。

在大多数数据中心场景中，合理的做法是：

• 共识层假设 crash-recovery，加上端到端的数据校验（checksum）来应对静默损坏。
• 应用层假设 omission + performance，设计合理的超时、重试和降级策略。
• 只在需要抵御恶意行为的场景（如公链、多方不互信的协作系统）才使用 Byzantine 容错。

分层防御

实际系统通常采用分层防御（Defense in Depth）的策略，在不同层级应对不同类型的故障：

没有哪一层能独自解决所有问题。磁盘 ECC 能修正单 bit 错误，但修不了固件 bug 导致的整扇区错误。共识协议能容忍节点崩溃，但容不了所有节点同时读到了损坏的数据。分层防御的思路是：每一层处理它能处理的故障，剩下的留给上层。

六、结论

故障不是二元的。在”完全正常”和”完全崩溃”之间，存在一个连续的光谱：偶尔丢包、间歇性变慢、静默数据损坏、时钟漂移、部分分区。这些灰色地带的故障才是生产环境中最常见、最难检测、最影响系统可靠性的。

故障模型的选择是系统设计的第一个决策，它决定了你需要多少副本、用什么共识算法、怎么做故障检测、怎么验证正确性。选弱了，系统在灰色故障面前裸奔。选强了，成本和复杂度让你无法承受。

几个带走的判断：

1. 生产系统的故障模型至少应该覆盖 crash-recovery + omission，并认真考虑 performance 故障的影响。
2. 故障检测不存在完美方案。phi accrual detector 和 SWIM 比固定超时好，但本质上仍然是在误报率和检测延迟之间权衡。
3. 数据完整性不能只依赖硬件。端到端校验（从写入到读取的全链路 checksum）是应对静默损坏的必需品。
4. 混沌工程不是选做题。如果你没有在生产或类生产环境中主动注入过你声称能容忍的故障类型，你的”容错”就是未经验证的假设。

参考资料

论文

• Cristian, F. “Understanding Fault-Tolerant Distributed Systems.” Communications of the ACM, 34(2), 1991. 故障分类层级的经典来源。
• Lamport, L., Shostak, R., Pease, M. “The Byzantine Generals Problem.” ACM Transactions on Programming Languages and Systems, 4(3), 1982. Byzantine 故障模型的定义。
• Chandra, T.D., Toueg, S. “Unreliable Failure Detectors for Reliable Distributed Systems.” Journal of the ACM, 43(2), 1996. 不完美故障检测器的理论框架。
• Hayashibara, N., Defago, X., Yared, R., Katayama, T. “The Phi Accrual Failure Detector.” IEEE Symposium on Reliable Distributed Systems, 2004. phi accrual 故障检测器。
• Das, A., Gupta, I., Lampson, B. “SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol.” IEEE/IFIP DSN, 2002. O(1) 消息复杂度的故障检测。
• Bairavasundaram, L.N., et al. “An Analysis of Data Corruption in the Storage Stack.” ACM Transactions on Storage, 4(3), 2008. 磁盘静默数据损坏的实证研究。
• Bailis, P., Kingsbury, K. “The Network is Reliable.” ACM Queue, 12(7), 2014. 网络分区频率的综述。
• Huang, P., et al. “Gray Failure: The Achilles’ Heel of Cloud-Scale Systems.” HotOS, 2017. 灰色故障的定义和案例分析。

事故报告与工程文档

• Amazon Web Services. “Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region.” 2011. AWS EBS 级联故障事后复盘。
• Cloudflare. “Incident report on memory leak caused by Cloudflare parser bug.” 2017-02-23. Cloudbleed 事件官方报告。
• CockroachDB Documentation. “Clock Synchronization.” 时钟偏移检测和处理机制。

工具

• HashiCorp memberlist: SWIM 协议的 Go 实现（github.com/hashicorp/memberlist）。
• Apache Cassandra: phi accrual failure detector 的生产级实现。
• LitmusChaos / Chaos Mesh: Kubernetes 原生的混沌工程框架。
• tc netem / toxiproxy: 网络延迟和故障注入工具。

上一篇：FLP、CAP 与不可能性结果 下一篇：端到端论证