故障模式运行手册：多 AZ 与 Aeron 边界场景

凌晨三点出故障时，你需要的是一张表，而不是一套理论。本运行手册涵盖最常触发 on-call 告警的两类故障：基础设施级故障（AZ 丢失、跨 AZ 延迟、区域级事件）和 Aeron 特有的边界场景（media driver 崩溃、archive I/O 错误、组件失同步、mark 文件损坏、日志缓冲区溢出）。针对每一类，你都能拿到数据丢失风险、可用性影响、恢复复杂度以及修复方案。

说明

本页是面向运维的。它告诉你什么会出故障、出了故障该怎么办，以及每种修复方案如何影响 p50、p99 和吞吐量。关于 Raft 共识、日志复制、media driver 与恢复背后的协议层机制，请参阅 The Aeron Files——我们只做引用，不做重复。

多 AZ 与跨区域故障

基础设施故障归根结底都是法定人数（quorum）的问题。丢掉少数节点不影响运行；丢掉多数节点就会宕机。下表是快速查询表。

场景	数据丢失风险	可用性影响	恢复复杂度	修复方案
AZ 故障（少数节点）	无	无（法定人数仍满足）	低——AZ 恢复后自动追赶	等待 AZ 恢复；节点自动重新加入并追赶。确保节点分散在各 AZ（3 节点集群每个 AZ 放 1 个）
AZ 故障（多数节点）	未提交的消息	完全不可用	高——需人工介入	在各 AZ 之间重新平衡节点分布；恢复故障节点或在健康 AZ 中新建节点
跨 AZ 延迟突增	无	降级（提交变慢、误触发选举）	低——调整超时参数	为跨 AZ 部署调大选举/心跳超时；使用 placement group 以最小化延迟
区域级故障	可能发生	完全不可用	极高——跨区域恢复	启用 DR 区域的备用集群；从跨区域复制的备份（快照 + 日志）中恢复

跨 AZ 延迟会推高 p50 并触发误选举

跨 AZ 延迟突增很隐蔽，因为它既不丢数据，也不会造成硬性宕机——只是提交变慢、伴随虚假的 leader 选举。每一次跨越 AZ 边界的提交都会把往返时延叠加到中位数路径上，于是 p50 攀升，长尾也随之而来。更糟的是，一旦心跳开始错过截止时间，集群就会发起误选举并陷入停顿。修复办法是为跨 AZ 部署调大选举/心跳超时，并使用 placement group 把往返时延压到最小。

节点分布策略

节点分布是基础设施侧影响最大的单个杠杆。它是一个延迟与韧性之间的权衡，你必须有意识地做出选择。

3 节点集群跨 3 个 AZ（推荐）

• 任意单个 AZ 故障 → 法定人数仍满足（2/3）。
• 权衡：每次提交都要承担跨 AZ 延迟（leader 必须复制到至少一个其他 AZ）。

3 节点集群分布在 2 个 AZ（延迟优化）

• AZ-b 故障 → 法定人数仍满足（AZ-a 中有 2/3）。
• AZ-a 故障 → 法定人数丢失（AZ-b 中只有 1/3）。
• 权衡：延迟更低（leader + 一个 follower 同处一个 AZ），但故障容忍能力不对称。

关键要点

节点分布的决策本质上是延迟与韧性之间的权衡。对于撮合引擎，常见模式是：把所有 Raft 节点放在同一个 AZ（提交延迟最低），并在另一个 AZ 使用 Cluster Standby（在不引入提交路径延迟的前提下获得韧性）。这样你既能拥有同 AZ 的提交延迟，又具备跨 AZ 的灾难恢复能力——两全其美，但需要 Premium。

Aeron 特有的边界场景

这些故障不会出现在通用的分布式系统手册里。它们源自 Aeron 的组件模型：Media Driver、Consensus Module 和 Service Container 是相互独立的部件，可以各自独立地发生故障。

场景	数据丢失风险	可用性影响	恢复复杂度	修复方案
Media Driver 崩溃	无	单节点宕机	低——重启节点	重启整个节点（Media Driver + Consensus Module + Service Container）；排查根因（driver bug、资源问题）
Archive 录制失败（I/O 错误）	无	降级至完全不可用（如果发生在 leader 上）	中——将节点下线	将节点下线；修复 I/O 问题（更换磁盘、修正权限）；清空并重启以从其他节点重建
Consensus Module 与 Service Container 失同步	无（但状态陈旧）	降级（不再处理消息）	中——需要健康监控	为所有组件实现存活检查；若 service container 宕机则重启整个节点
Mark 文件损坏	无	单节点无法启动	低——清理 mark 文件	从 clusterDir 和 aeronDir 删除陈旧的 mark 文件；重启节点。确保没有重复进程在运行
日志缓冲区溢出（termLength 过小）	无	降级（反压）	低——增大 termLength	在 MediaDriver 和 ConsensusModule 配置中增大 termLength；通过协调的滚动重启来重启集群

关键要点

Media Driver 崩溃这一场景凸显了一个重要的架构要点：Media Driver、Consensus Module 和 Service Container 是相互独立、可独立故障的组件。在生产环境中，你需要为每个组件设置健康检查，而不仅仅是检查 JVM 进程。一个 JVM 在运行、但 Service Container 已崩溃的节点，在进程监控看来是健康的，实际上却没有在处理任何消息。请实现应用级的健康检查，验证这三个组件都在正常工作。

理解 mark 文件

Mark 文件是 Aeron 用来检测同一目录下是否已有另一个实例在运行的哨兵文件。损坏通常发生在以下情况：

• 进程未经清理就被杀掉（kill -9）。
• 两个进程意外共用了同一个 aeron 目录。
• 文件系统损坏。

修复方法很简单：删除 mark 文件并重启。但务必先确认没有其他进程正在使用同一目录。

注意

在删除 mark 文件之前，请确认没有活动进程正在使用同一个 clusterDir 或 aeronDir。在真实进程仍在运行时删除 mark 文件，等于招致两个进程共用一个目录——而这恰恰正是损坏最初产生的原因。

日志缓冲区溢出

当消息比预期更大、或突发速率超过 term buffer 容量时，反压会层层传导，最终演变成可用性问题：

修复办法是增大 termLength，但要记住 term buffer 容量规划中的 L3 缓存约束：term buffer 应小于 L3 缓存大小的 1/3。

termLength 卡在吞吐量与 L3 缓存之间

termLength 过小会限制吞吐量，最坏情况下还会触发选举，使整个集群陷入停顿。但你也不能简单地把它拉满：term buffer 必须保持在 L3 缓存大小的 1/3 以下，否则就会把缓存撑爆，并以 p99 的代价偿还。把它调大以缓解反压，但要在缓存上限处止步。term buffer 与 publication 流的具体机制详见 The Aeron Files。