裂脑与仲裁
在双活架构中，站点间链路中断会造成一种特殊状态：两端设备都健康、都能对外提供服务，但彼此不可见。这就是裂脑（Split-Brain）。如果两端都继续接受写入，各站点会独立产生新数据，两边都认为自己是最新状态，事后没有自动机制可以判断谁对谁错。仲裁机制的作用就是在链路中断时给出一致结论：只允许一侧保留写权限，另一侧停止写入或转为只读，从而保证数据只有一条演进主线。
基本信息
| 裂脑定义 | 两端均可运行但互不可见，各自产生写入 |
|---|---|
| 直接后果 | 数据分叉，恢复时需要人工判定取舍 |
| 常见仲裁方式 | 第三方站点、优先级站点、共享仲裁设备 |
| 仲裁目标 | 保证任何时刻只有一侧拥有写权限 |
| 判定依据 | 站点存活状态、链路状态与预设优先级 |
| 新依赖 | 仲裁点自身不可用时需要兜底策略 |
典型使用场景
- 站点间链路中断时，判定由哪一侧继续提供写服务
- 仲裁设备或仲裁站点计划维护，确认维护期间的双活行为
- 演练中模拟链路中断，验证仲裁是否按设计执行
- 一方故障恢复后重新加入，处理差异数据的同步与覆盖方向
- 扩展到三个以上站点时，评估仲裁复杂度与成本是否可接受
- 两端均受损时的业务取舍决策，明确由谁拍板与依据什么
仲裁方式对比
| 方式 | 原理 | 主要优缺点 |
|---|---|---|
| 第三方站点仲裁 | 独立站点参与多数表决 | 可靠性高，但需要额外站点与链路 |
| 优先级站点 | 预先指定某一侧优先 | 实现简单，优先侧故障时可能无法写 |
| 共享仲裁设备 | 两端争夺同一设备上的锁 | 成本低，但设备本身是单点 |
| 人工决策 | 由值班人员判断并执行 | 无技术依赖，但耗时且依赖经验 |
| 存储内部仲裁 | 由阵列自身机制判定 | 无需额外组件，能力受产品限制 |
仲裁的目标不是判断哪一侧更优，而是保证任何时刻只有一个写入方。多数方案的判定依据是站点存活状态与预设优先级，因此必须为每一种组合写明结果，包括两端同时认为对方失联、仲裁点不可达、仲裁点在线但两侧链路质量不同等边界情况。
仲裁点自身会成为新的依赖。如果仲裁部署在第三个站点，该站点与原两站点之间的链路同样需要冗余；如果仲裁依赖共享设备，该设备必须位于独立故障域。否则一次故障可能同时让双活失去保护与仲裁能力，届时只能靠人工决策，恢复时间无法预估。
裂脑场景推演
裂脑场景推演
# 1) A 与 B 之间链路中断，A、B、仲裁点均在线 -> 按仲裁规则判定
# 2) A 与 B 链路中断，且 A 到仲裁点也不可达 -> A 是否降级只读
# 3) 仲裁点整体不可达 -> 兜底策略是什么
# 4) B 侧阵列故障，A 与仲裁点正常 -> B 恢复后如何重新加入
# 每种场景都要写明期望结果与需要人工介入的条件