分布式系统故障模型
做分布式系统，最怕什么？不是代码写得烂，而是你根本猜不到系统会怎么死。我这些年踩过的坑，十有八九都和故障模型有关。今天咱们就把三种核心故障模型聊透：崩溃故障、拜占庭故障、网络分区。你想想看，这些模型其实是给系统「定性」——你到底能容忍多坏的队友？
1. 崩溃故障
这是最「老实」的故障。节点要么正常工作，要么彻底停摆。没有中间态，不会乱发消息，不会篡改数据。说白了，就像一个只说真话的同事，最多突然请假不来了。
我在做分布式数据库的复制层时遇到过经典案例：主节点挂掉，从节点升主，一切看起来完美。但问题是——挂掉的主节点其实只是网络闪断，它自己又恢复了，还以为是主。结果两个主节点互相打架，数据就乱了。原因很简单，崩溃检测超时设置得太短。
- 特征：节点停止响应，不会产生错误消息
- 检测难度：低，心跳超时即可
- 经典算法：Paxos、Raft 都假设最多 f 个节点崩溃
- 避坑：不要用固定超时，加一些随机抖动，我曾经吃过这个亏
提示：Raft 的任期机制就是用来防「假死恢复」的。新主收到旧主的请求，直接忽略。你写代码时也要理清楚任期或者 epoch 的逻辑。
2. 拜占庭故障
这名字听起来唬人，其实就是「恶意节点」。它不按套路出牌：可以随意伪造数据、选择性发消息、甚至合谋攻击。你想想看，如果你的队友里混进来一个间谍，要达成共识有多难。
我记得在区块链项目里模拟过拜占庭场景。有一个节点明明收到了交易，却在投票时故意说没收到。结果整个网络需要 3f+1 个节点才能容忍 f 个恶意节点。嗯，代价很高，但这是数学保证。
- 特征：任意错误行为，包括欺骗、合谋、延迟
- 检测难度：极高，需要密码学签名和消息一致性校验
- 经典算法：PBFT、HotStuff、各种 BFT 变体
- 避坑：不要假设节点会遵守协议。我曾经在测试中故意篡改消息体，结果一个号称 "BFT-ready" 的系统直接写入了脏数据
警告：零信任网络下，拜占庭故障是常态。因为网络中的任何节点都有可能被攻破，你不能假设它「诚实」。签名是基本要求，但还不够，你还需要容忍伪造签名的攻击。
3. 网络分区
这个坑我掉进去过不知多少次。网络分区不是某个节点挂了，而是节点之间彻底失联，但每个节点自己都活得好好的。它们会各自为政，直到网络恢复。最头疼的是——分区间没法通信，每个分区都可能选出一个新主。
其实网络分区比崩溃更麻烦。因为你没法判断对方是挂了还是被分区了。我曾经在 Kubernetes 环境下遇到过节点之间 iptables 规则冲突导致分区，结果两个分区各选了一个 leader，数据开始冲突，最后只能从备份恢复。
- 特征：部分节点连通，部分节点完全隔离
- 检测难度：中，需要分布式故障检测器 + 多数派机制
- 经典算法：Raft 要求多数派决策，少数派不可写入；Paxos 用 Quorum 保证一致性
- 避坑：我曾经以为「节点超时=崩溃」，结果忽略了分区导致脑裂。记住：一定要用多数派（Majority Quorum），不要用奇数节点裸奔
核心要点：网络分区时，任何「单中心决策」都会失效。零信任网络下，节点间的通信路径不可靠，你必须假设任意时刻都可能出现分区，然后设计多数派协议来保护状态。
| 故障类型 | 行为特点 | 检测难度 | 容忍代价 | 零信任关联 |
|---|---|---|---|---|
| 崩溃故障 | 节点沉默，没有中间态 | 低（心跳超时） | 至少 f+1 个副本 | 需要持续认证心跳 |
| 拜占庭故障 | 节点可任意作恶 | 高（需密码学） | 至少 3f+1 个节点 | 必须假设所有节点不可信 |
| 网络分区 | 部分连通，部分隔离 | 中（需多数派） | 需 Quorum 协议 + 降级策略 | 通信路径必须验证完整性 |
实战建议：你在设计零信任一致性协议时，先问自己三个问题——1）节点会不会挂？2）节点会不会说谎？3）网络会不会断开？这三个问题的答案决定了你该选哪种故障模型。大多数业务系统只考虑崩溃和网络分区就够了，但涉及金融、身份认证的，一定要上拜占庭容错。
别忘了：故障模型不是选择题，而是组合题。一个系统可能同时遭遇崩溃、拜占庭和网络分区。我曾经在压力测试中遇到过这种「三重暴击」：主节点挂掉的同时，另外一个节点被攻陷开始发假数据，而且网络出现了断续。最后崩溃的是我们的人，不是系统。所以，为最坏情况设计，但先验证最常见模型。