撮合引擎高可用架构：从冷热备到毫秒级无感切换
TL;DR
撮合引擎是有状态的内存系统：要做到“无感切换”，核心不是复制一份内存快照，而是把引擎抽象成确定性状态机，通过复制指令日志（复制状态机/RSM）让主备保持同一条事实来源；再用 Raft/Paxos 这类共识算法保证日志顺序一致，并配合租约/任期（term）+ fencing 解决脑裂，才能同时逼近RPO=0 与毫秒级 RTO。
关键要点与工程坑点
- 先把问题讲清：撮合引擎的状态是订单簿快照；HA 指标里，交易系统通常要求 RPO=0（不丢单/不丢成交）与极低 RTO（故障切换毫秒～亚秒）。传统“数据库主从复制”很难兼顾两者。
- 复制状态机（RSM）才是正解：不要试图持续复制整份订单簿内存，而是复制“产生状态的指令序列”（下单/撤单等）。只要指令顺序完全一致，状态就必然一致——日志因此成为 Single Source of Truth。
- 确定性是硬前提：撮合主循环必须可重放、可验证。常见踩坑包括：用系统时间/随机数参与逻辑、遍历无序 HashMap 导致迭代顺序漂移、多线程并发引入不可控调度差异。工程上通常选择单线程串行应用日志来换确定性与可测试性。
- 共识保证“同一条日志”：以 Raft 为例：Leader 排序写入复制日志，只有复制到多数派（quorum）才算 committed；这对应强同步复制，换来零数据丢失，但写延迟会被 RTT 拉高（尤其跨机房）。
- 脑裂比宕机更可怕：误判故障触发双主会造成不可逆的不一致。常见做法是租约（lease）+ 自我降级（self-fencing），并辅以任期/epoch：任何携带旧 term 的请求/消息都必须被拒绝。
- 演进路径要现实：从冷备（快照+手切）→ 温备（日志重放）→ 热备自动切换（协调器/共识+fencing）→ 分片/多活，是一条更可落地的路线；越往后复杂度越指数上升。
适用场景
- 交易所/券商核心撮合：7x24 运行、停机窗口极小，且对“绝不丢单”有硬要求的系统。
- 强一致低延迟的内存服务：除撮合外，任何可以抽象为确定性状态机的关键链路（风控决策、限额/仓位状态等）都能复用这套思路。
- 需要明确工程权衡的团队：愿意用同步复制换一致性，并能通过网络/部署距离/GC 调优等手段把延迟压下去。
进一步探索
如果你在做交易系统的容灾与可用性设计，建议把“确定性状态机 + 共识日志 + fencing”作为主线来评审方案与排雷。更多端到端落地思路可查看我们的 交易系统整体解决方案。