本页目录
故障模型
节点可能崩溃、可能失联、可能撒谎。从 crash-stop 到 Byzantine,故障模型的每一次升级都让协议设计难度翻倍——而工程中"超时多长算故障"本身就是一个没有正确答案的权衡:太短误判活节点,太长系统空等。
故障分类
Crash-Stop (Fail-Stop)
节点停止执行后不再重启。这是最简单的故障模型——一旦节点 crash，它就永远不产生新的输出。共识协议（Paxos/Raft）在这个模型下有简洁的证明。
特点：不需要持久化（crash 后节点不需要恢复 log），状态可以放在内存。但实践中极少数系统是真正的 crash-stop——大多数系统需要 crash-recovery。
Crash-Recovery
节点停止，但经过一段（任意）时间后重启并恢复执行。恢复需要从持久存储（WAL/journal）重放 pre-crash 状态。这是最实际的故障模型——Raft/etcd 就是针对 crash-recovery 设计的。
恢复后的关键问题：重启的节点必须能证明它的 log 没有丢失——即 log 被持久写入并在 crash 前确认了。这就是 Raft 为什么要求 fsync 日志条目后才回复 leader。
Byzantine (拜占庭) 故障
节点可以任意行为——包括发送伪造消息、选择性响应、蓄意破坏。不仅是恶意攻击：内存 bit-flip (宇宙射线)、固件 bug、网络设备错误转发都可能产生 Byzantine 行为。
Byzantine 比 crash 难得多：Paxos/Raft 只容忍 f 个 crash 就需要 2f+1 个节点；PBFT（Practical Byzantine Fault Tolerance）需要 3f+1 个节点来容忍 f 个 Byzantine 节点。
原因：Byzantine 节点可以对不同的诚实节点说不同的话——诚实节点无法区分"对方在撒谎"和"网络丢包"。PBFT 的 3f+1 的下限已被证明是必要的。
实践中的分布
实际系统极少需要 Byzantine 容错——在一个封闭的数据中心/集群中，crash-recovery 覆盖了绝大多数故障。Byzantine 主要出现在：
- 区块链/加密货币（节点互不信任）
- 跨组织协作（没有共同信任根）
- 极其关键的基础设施（Spanner 用 TrueTime 防止了某些 Byzantine 式时钟攻击）
网络分区
分区不等于 crash——节点仍在运行，能接受客户端请求，但不能与其他节点通信。分区是对 CAP 定理的核心威胁：分区发生时，你必须选择一致或可用。
对称分区 vs 非对称分区
- 对称分区：集群被等分为两部分，每部分都有节点的多数 → (用 Raft) 只有有 majority 的那一半能选举 leader 并继续服务
- 非对称分区：单个节点与其他所有节点断连 → 它不能成为 leader，也不会造成脑裂
Split-Brain (脑裂)
多 leader 系统 + 分区 = 两个分区各自选举了 leader → 两边同时接受写入 → 分区恢复时冲突。经典的解决方案：
- Raft/Paxos: 永远只有 majority partition 能有 leader（数学保证）
- 系统级防御：STONITH (Shoot The Other Node In The Head) → fence 旧 master 甚至直接断电
超时
分布式系统的核心张力：超时太短 = 误判 crash (false positive)；超时太长 = 故障检测慢 (增加不可用窗口)。
Raft 的选举超时就是典型：150-300ms 随机化，既保证不同 candidate 有不同的超时（避免 split vote），又要足够长以覆盖正常的 RPC 延迟。
为什么没有"正确"的超时
网络延迟不是高斯分布——它有长尾（tail latency）。即使 p99 延迟是 10ms，p99.9 可能就跳到 100ms。如果你设 timeout=100ms，0.1% 的请求会误判为超时。如果设 timeout=1s，故障检测延迟就是 1s——这段期间系统不可用。
这个问题没有理论解，只有工程权衡。在实践中：用 φ-accrual failure detector（见 05 章）输出 suspicion level 而不是二值判断——让应用层决定"多大的怀疑值得做 failover"。
参考
- 论文: "Impossibility of Distributed Consensus with One Faulty Process" (FLP, 1985)
- 论文: "Practical Byzantine Fault Tolerance" (Castro & Liskov, 1999)
- 论文: "The φ Accrual Failure Detector" (Hayashibara et al, 2004)
Keywords: crash-stop, crash-recovery, Byzantine fault, network partition, split-brain, FLP, timeout, φ-accrual