Nomad 技术专栏 | 第九章：反脆弱——故障场景与自动恢复

这是 Nomad 系列文章的第九章。在上一章中，我们掌握了通过 API 指挥集群的能力。但在生产环境中，我们不仅要学会“指挥”，更要学会“放手”。

分布式系统的第一定律是：故障一定会发生。网络会抖动，硬盘会坏，机房会断电。优秀的编排系统不是保证不发生故障，而是在故障发生时，能够自动地、优雅地自愈。

本章我们将模拟几种最惊心动魄的故障场景——Leader 宕机、脑裂（网络分区）以及节点大规模失联，看看 Nomad 是如何展现其“反脆弱”能力的。

前言：控制面与数据面的隔离

在深入具体的故障场景之前，我们需要先定一颗“定心丸”：Nomad 采用了严格的控制面（Server）与数据面（Client）分离的设计。

这意味着：哪怕整个 Nomad Server 集群全部炸毁，只要 Client 节点还在运行，你部署的 Nginx、Redis、Java 应用都不会停止。它们会继续运行，只是暂时无法进行更新或扩缩容而已。这种设计最大程度地降低了管理层故障对业务层的影响。

1. 场景一：斩首行动——Leader Server 宕机

Leader 是集群中唯一能处理“写请求”（如提交 Job）的节点。如果 Leader 所在的服务器突然断电，会发生什么？

1.1 自动检测与选举

1. 沉默的瞬间：Leader 宕机后，心跳停止。
2. 检测 (Detection)：Follower 节点在等待 150ms - 300ms（随机超时时间）后，发现 Leader 没声音了。
3. 发起政变 (Election)：Follower 变身为 Candidate，发起新一轮 Raft 选举。
4. 新王登基：通常在 1 秒内，一个新的 Leader 会被选出。

1.2 对业务的影响

• 写入停滞：在选举期间（约 1-2 秒），集群无法接受新的 job run 请求，API 会返回 500 错误或重试提示。
• 读取降级：如果配置了 allow_stale = true，Follower 节点仍然可以响应只读查询（如查看任务状态），但数据可能有几毫秒的延迟。
• 业务无感：正在运行的容器完全不受影响。

2. 场景二：大脑分裂——网络分区 (Split Brain)

这是分布式系统中最棘手的问题。假设你有 5 个 Server：3 个在机房 A，2 个在机房 B。如果两个机房之间的光缆被挖断了，会发生什么？

2.1 多数派原则 (Quorum)

Nomad 遵循 Raft 的 2F+1 黄金法则。

• 机房 A (3 节点)：拥有 3/5 的选票，满足“大多数”。它们会选出一个 Leader，继续正常工作。
• 机房 B (2 节点)：只有 2/5 的选票，无法凑齐大多数。它们无法选出 Leader。

2.2 少数派的行为

机房 B 的 Server 会进入“避世”状态：

• 拒绝写入：防止数据不一致。
• 不断重试：它们会不断尝试联系其他节点，直到网络恢复。

2.3 恢复与治愈

当光缆修好后：

1. 机房 B 的节点发现机房 A 的 Term（任期号）更高。
2. 它们会自动降级为 Follower。
3. 它们会从机房 A 的 Leader 那里拉取最新的日志，回滚自己本地未提交的脏数据（如果有），并同步到最新状态。整个过程无需人工干预。

3. 场景三：断臂求生——Client 节点失联

相比于 Server 故障，Client 故障发生的频率要高得多。当一台运行着关键业务的 Client 机器突然失联（Heartbeat Timeout），Nomad 会如何应对？

3.1 判定死亡

我们曾在第六章提到，Server 不会立即判定 Client 死亡，而是会给一个宽限期（默认心跳 TTL 的 2 倍左右）。一旦 Leader 确认该节点状态为 down：

3.2 重新调度 (Reschedule)

Leader 会触发一次特殊的评估（Evaluation）：

1. 标记丢失：将该 Client 上所有运行的 Allocation 标记为 lost。
2. 创建替补：根据 Job 的定义（比如 count = 3），调度器发现当前只有 2 个副本存活，不满足期望。
3. 寻找新家：调度器在剩余的健康 Client 中寻找资源充足的节点，创建新的 Allocation。

3.3 自动回切 (防止抖动)

如果原来的 Client 只是重启了一下，1 分钟后又回来了，怎么办？

• 原来的 Client 重新注册，发现自己身上的任务已经被标记为 lost。
• 它会自动清理这些旧任务（GC）。
• Nomad 不会自动把任务迁移回来（除非使用了特定的重平衡策略），以防止任务在节点间反复横跳。

4. 总结：反脆弱的设计哲学

Nomad 的故障处理机制体现了几个核心哲学：

1. 悲观的共识，乐观的执行：Server 端用最严谨的 Raft 保证数据不丢；Client 端用最宽松的本地自治保证业务不停。
2. 自动化优先：无论是 Leader 选举还是网络分区恢复，全程无需运维人员敲击任何命令。
3. 可用性与一致性的权衡：在网络分区时，Nomad 选择CP (Consistency)，宁可暂停写入也不允许脑裂导致的数据错乱（不同于 Consul 的 AP 模式服务发现）。

理解了 Nomad 如何在风暴中生存，下一章，我们将探讨运维与监控。如何配置 Prometheus 来收集这些故障指标？如何通过日志提前预判集群的亚健康状态？我们将为你构建一套完整的 Nomad 可观测性体系。