Leader 选址与优雅退位

在 Raft 集群中，Leader 承载所有写入，因此 Leader 落在哪里 决定了延迟。当节点跨可用区部署时，位于远端 AZ 的 Leader 会给每一次已提交的操作叠加一次跨 AZ 往返。本页比较 Aeron Cluster 与 SOFAJRaft 在 Leader 指派上的不同处理方式，以及在故障切换后将 Aeron 的 Leader 引导回低延迟可用区的运维方法。

至于字节级别的选举内部机制——term、canvass、投票记录——请参阅 The Aeron Files。本页讲的是运维视角：两种实现各自提供了哪些 Leader 选址控制能力，以及当这些能力不足时该怎么办。

为什么 Leader 选址很重要

在延迟最低的配置中，Leader 与驱动它的工作负载位于同一个 AZ。共识流量与热路径都保持在同一个区内，因此 p50 和 p99 保持紧凑。

Leader 故障之后，Raft 会从存活的成员中选出一个新 Leader。这次选举由协议决定——超时与投票—— 而非由可用区决定。新 Leader 可能落在另一个 AZ，从那一刻起，共识在每一笔订单上都要跨越 AZ 边界。

Leader 指派：Aeron Cluster vs SOFAJRaft

两种实现对”运维人员能在多大程度上控制 Leader”持不同立场。

能力	SOFAJRaft	Aeron Cluster
显式 Leader 转移	支持——`Node.transferLeadershipTo(PeerId)` 通过向目标节点发送 `TimeoutNowRequest` 触发立即选举，从而把 Leader 交给指定节点	没有将 Leader 转移到指定节点的原生 API
选举优先级 / 偏好	支持——每节点可配 `ElectionPriority`（`NodeOptions.setElectionPriority`）；高优先级节点更受偏好，`0` 表示”永不当 Leader”	无优先级机制；所有投票成员都是平等的候选者
将 Leader 固定到某个 AZ/节点	可通过优先级 + 转移实现	原生不支持
触发 / 影响一次选举	`transferLeadershipTo` 会触发一次定向选举	没有命令可以触发选举或把 Leader 移到指定节点

故障切换之后意味着什么

由于 Aeron 没有 Leader 指定 API，那个直觉上的办法——关掉选址糟糕的 Leader，寄希望于正确的节点胜出—— 并不可靠：下一次选举可能把 Leader 交给 另一个 远端节点。ClusterTool 的命令（is-leader、list-members、suspend/resume、shutdown）能让你查看成员关系并优雅地关闭某个节点，但它们都无法请求选举倒向某个特定节点。

运维方法：受控退位

在没有原生转移 API 的情况下，可靠的做法是 先验证，再重选——预检查期望的目标节点，然后让当前 Leader 退位以触发一次新的选举。这比强行关闭节点更可靠，尽管选举结果仍不保证一定落在目标节点上。

阶段一 —— 预检查目标节点

在改动任何东西之前，确认目标节点健康且日志已完全追平。一个复制落后的目标节点可能在选举中落败，或即便胜出也会因追赶而卡顿。先验证，正是让重选变得足够可预测、从而有实用价值的关键。

阶段二 —— 让 Leader 退位

优雅地让当前 Leader 退位以触发一次新的选举。配合预检查，这会把结果偏向已验证的节点—— 远比强关后听天由命可靠，但仍不像 SOFAJRaft 的 transferLeadershipTo 那样具有确定性。

阶段三 —— 确认选址

核实新 Leader 是否落在预期的 AZ（is-leader / list-members）。若没有，重复退位流程。一旦 Leader 回到热路径所在的区，共识与工作负载再次共享同一个 AZ，p50/p99 便回落到其单 AZ 基线。