Cluster Standby 与多 AZ 高可用设计

备节点是高可用不再与延迟相互拉扯的关键所在。Aeron Premium 的 Cluster Standby 为你提供跨 AZ 韧性、亚分钟级恢复，以及永不阻塞订单簿的快照——而且这一切都无需把 Raft 共识拖拽到多个可用区之间。本页综合阐述其设计思路，并展示每一项特性如何映射到你的延迟与吞吐指标。

说明

本页聚焦于 Cluster Standby 在生产环境中的实际表现，以及它如何影响 p50、p99 和吞吐量。关于日志复制、共识与恢复的协议层机制，请参阅 The Aeron Files——我们只做引用，不做重复。

三大设计支柱

Cluster Standby 建立在三项特性之上，每一项都对应解决一个具体的生产痛点。它们协同工作：快速快照让主集群不被阻塞，原地身份切换带来亚分钟级 RTO，跨 AZ 部署提供真正的高可用。

• 快（Fast） —— 快照在备节点上执行，主集群因此从不停止处理。
• 身份切换（Identity switch） —— 备节点原地转换为完整的 Raft 成员，大幅缩短恢复时间。
• 稳（Stable） —— 备节点可运行在不同的可用区，提供真正的跨 AZ 韧性，同时避免在热路径上承担跨 AZ Raft 复制的延迟代价。

备节点是温备（warm），而非冷备。它会处理每一条消息以维护状态——而不仅仅是存储数据。

快：快照只在备节点上执行

在 OSS Aeron 中，快照是热路径延迟的隐形杀手。Leader 必须暂停以序列化其全部内存状态，在此暂停期间订单处理速度跌至零——这是一次彻底的 stop-the-world 事件。

没有 Cluster Standby（OSS）

订单处理速度 (Order Processing Speed)
  ████████████████░░░░░░████████████████
                  ↑
          Snapshot window:
     Processing speed drops to ZERO
     while leader takes snapshot

• Leader 节点必须暂停以序列化其全部内存状态。
• 在快照期间，订单处理速度 = 0 —— 一次彻底的 stop-the-world 事件。
• 集群运行 3 个节点，每个节点都有自己的 archive，全部参与 Raft。

有 Cluster Standby（Premium）

订单处理速度 (Order Processing Speed)
  ████████████████████████████████████████
     (no interruption — snapshot happens on standby)

• 快照在备节点上执行，而非 Leader。
• 主集群从不为快照而暂停。
• 备节点处理每一条消息以维护状态，然后独立地执行快照。
• 在备节点上执行的快照会回传给活跃集群。

关键洞见

对于处理数百万订单的撮合引擎而言，哪怕只有 100ms 的快照暂停都是灾难性的——它会在订单簿中制造一个空档。这段暂停会直接落在 p99 上（更糟的是落在 max 延迟上），而 p50 却看似干净、具有迷惑性。把快照搬到备节点上，可以彻底消除这段暂停。这是在生产级交易系统中选择 Premium 而非 OSS 的最有力论据之一。

身份切换：备节点原地转换为 Raft 成员

当某个节点发生故障时，备节点并不会启动一个新实例。它会从备节点原地转换为完整的 Raft 共识成员。由于它一直在处理每一条消息，状态早已驻留在内存中——这次切换本质上只是翻转一个标志位，而不是重建状态。

没有 Cluster Standby —— 恢复时间 > 5 分钟

在 OSS Aeron 中，当某个节点发生故障时：

1. 开启新EC2 —— 启动一个新的 EC2 实例（取决于该 AZ 的库存）。
2. 向新Leader拿最新Snapshot —— 从新 Leader 获取最新快照。
3. 追最新的logs —— 重放日志以追平进度。
4. 加入成为Member —— 作为集群成员加入。

恢复时间：> 5 分钟 —— 而且取决于该 AZ 是否有可用实例。

有 Cluster Standby —— 恢复时间 < 1 分钟

在使用 Premium Standby 时，当某个节点发生故障时：

1. 备节点通过指令成为新Member节点 —— 备节点收到指令以转为成员节点。
2. 追最新的logs —— 追平最新日志（由于备节点已是温备，工作量极小）。
3. 加入成为Member —— 作为成员加入。
4. StandBy节点打快照 —— 备节点执行快照（后台进行，不阻塞）。

恢复时间：< 1 分钟。

关键洞见

关键的差异在于备节点已经把状态保存在内存中——它一直在处理每一条消息。它无需从头下载快照并重放日志。这正是 5 分钟以上的停机与亚分钟级恢复之间的区别。在你的可用性预算里，这道鸿沟决定了全局成败。

稳：跨 AZ 热备

接下来这部分正是保护延迟的关键。备节点在不同的可用区中组成一个独立的备份集群，通过日志复制与主集群相连。你由此获得跨 AZ 高可用，却无需为每一次 Raft 提交支付跨 AZ 往返开销——因为 Raft 法定多数（quorum）始终保持在同一个 AZ 之内。

恢复目标

指标	数值
RTO	< 60 秒
RPO	< 跨 AZ / 跨区域延迟（通常为个位数毫秒）

关键洞见

RPO 受限于跨 AZ 延迟，意味着你最多只会丢失几毫秒的数据——本质上就是故障发生那一刻仍在传输途中的消息。对于撮合引擎而言，这至多是寥寥几笔订单。再结合 < 60 秒的 RTO，这便提供了真正生产级的高可用，且不牺牲热路径延迟——而这份低延迟正源于把所有 Raft 节点都保留在同一个 AZ 内。你既保住了紧凑的 p50/p99，又 能在 AZ 失效时存活下来。

能力详解

Cluster Standby 远不止是一个故障切换技巧。它的核心特性开启了多个截然不同的生产用例。

核心特性

• 温备节点 —— 它们处理每一条消息，但不参与 Raft 共识。
• 无需同步复制 —— 因此备节点不会对 Leader 施加任何反压（back-pressure）。正是这一点，使得主集群的吞吐量与尾延迟不受备节点的影响。

跨数据中心复制

• 灾难恢复 —— 在另一个数据中心或区域运行一个备份集群。
• 可级联（Daisy chainable） —— 一个备节点可以继续向更远的备份集群复制：DC1 → DC2 → DC3。

后台快照

• 快照在备节点上执行，并回传给活跃集群。
• 活跃集群从不为快照而暂停。

查询

• 备节点可以承接读查询，而不增加 Leader 的负载。
• 状态接近实时，受复制延迟所限。

节点替换

• 加入现有集群以替换故障节点 —— 一个命令行工具可将 Standby Node 转换为 Member Node。
• 滚动升级 —— 加入一个运行新软件版本的备节点，再下线旧节点。

动态成员管理已移入 Premium

动态成员管理支持已从 OSS 版本中移除，并被纳入 Cluster Standby（Premium）。在 OSS 中，你无法对运行中的集群动态地增加或移除节点。

关键洞见

级联（Daisy-chaining）对于全球化部署非常强大：主集群在新加坡，备集群在东京，而东京的备节点再向伦敦复制。每一跳都会给复制路径增加延迟——但主集群始终不受影响。节点替换工作流（备节点 → 成员的转换）同样是滚动升级的推荐方式，它远比原地升级更安全。

这些旋钮如何改变你的指标

Cluster Standby 从根本上是一项延迟保护特性。这些收益可以直接映射：

• p99 / max 延迟 —— 把快照从 Leader 上移走，消除了那种本会让尾延迟飙升的周期性 stop-the-world 暂停。将 Raft 法定多数保留在同一个 AZ 内，避免了给每次提交叠加跨 AZ 往返。
• 吞吐量 —— 备节点复制是异步的，因此不会对 Leader 施加反压。主集群以其同 AZ 法定多数所允许的最快速度提交，无论备节点距离多远、级联链有多少跳。
• p50 —— 出于同样的原因保持紧凑：没有任何法定多数成员跨越 AZ 边界，因此中位提交路径走的就是快速的同 AZ 路径。

简而言之：你获得了跨 AZ 高可用、< 60 秒 RTO 以及个位数毫秒级 RPO，而你的热路径运行起来就仿佛根本不存在备节点一样。