摘要
2026-05-07，Coinbase 因 AWS 美东一可用区冷却故障，使基于 Raft 的撮合引擎在该可用区失去仲裁，触发多小时平台级交易停摆。恢复需应急代码改动与手动集群重建。
时间线
- 单 AZ 冷却故障发生，置于同 AZ 的 5 节点中 3 节点离线
- Raft 仲裁丢失，撮合引擎不可用
- 滞留该 AZ 的 Kafka 积压进一步拖慢恢复
- 经应急代码改动与手动集群重建后恢复
根因
撮合引擎运行在 AWS 集群放置组（Cluster Placement Group）内以换取低延迟，导致 5 个 Raft 节点中有 3 个同处一个可用区；该 AZ 冷却故障使这 3 节点离线，仲裁破裂。同时 Kafka 负载滞留该受损 AZ，形成巨大积压，使恢复比单点故障复杂得多。
放大因素
为低延迟而做的同区共置，埋下单 AZ 依赖的隐性单点；Kafka 与撮合引擎同时受困于同一 AZ，放大故障。
缓解措施
实施撮合引擎跨 AZ 自动故障转移；改进仲裁恢复；增强消息中间件韧性；扩大灾备演练。
经验教训
性能导向的架构决策（如共置降延迟）可能制造隐藏的单 AZ 依赖，削弱云韧性；关键状态服务必须跨 AZ 分散仲裁。
检查清单
- 关键有状态服务跨多 AZ 分散仲裁节点
- 避免为低延迟牺牲可用区隔离
- 建立跨 AZ 自动故障转移与仲裁恢复
- 定期做 AZ 失效的灾备演练