"我们系统是同构双活"这句话，在券商语境里要立刻追问一句：活的粒度是什么？这篇把高可用架构的两个指标拆开，讲交易、清算、行情三类负载在双活与灾备上的不同落法，以及两个最容易翻车的坑——脑裂和纸面演练。
先定指标：RPO 和 RTO 是业务决策
两个指标经常被混着说，定义先分清：
- RPO（Recovery Point Objective）：灾难发生时最多丢多少数据，回答"往回退到哪个时间点"；
- RTO（Recovery Time Objective）：多久恢复服务，回答"停多长时间"。
关键是这两个指标按业务分别定，不是全公司一个数：
| 负载 | RPO | RTO | 理由 |
|---|---|---|---|
| 交易时段委托/回报 | 0（一笔不丢） | 分钟级 | 丢一笔委托是合规事件，不是技术事故 |
| 日终清算批量 | 可放宽（流水在库可重跑） | 小时级 | 批量状态可重建，代价是时间 |
| 行情分发 | 不敏感（断线补快照） | 分钟级 | 行情天然有重传与快照机制 |
指标从业务定下来，技术方案才有评判标准。反过来的顺序——先买了设备再凑指标——是灾备项目失败的标准开局。
交易时段 RPO=0 的技术路径
一笔委托的状态散落在三个地方：内存（撮合队列、柜台缓存）、消息流（网关到撮合的在途报文）、数据库（已落库的流水）。要做到"一端机房整个没了，一笔委托不丢"，三条路径都要堵：
- 内存状态实时复制：撮合引擎把每笔状态变更同步写到对端内存镜像（《灾备与同城双活：撮合状态怎么同步》篇展开过难点——高频小对象的复制一致性是硬骨头），对端是热 standby，接管即服务；
- 在途报文双发或重发：网关记录的原始报文 append-only，对端接管后对账重放；
- 落库数据同步复制：同城光纤 1~2ms 的同步写，两端都成功才应答客户端。
注意同步复制的延迟账：同城机房间距几十公里，光纤往返 1~2ms，摊在委托预算里可接受；异地（几百上千公里）30ms 以上，同步复制不可用——这是"异地做不到 RPO=0"的物理原因，不是预算原因。所以异地灾备的定位天然就是"防同城级灾难"，RPO 分钟级、RTO 小时级，接受它。
双活与主备：批量清算天然主备
双活（两端同时接流量）和主备（备端空转）的选择也被业务决定：
- 交易链路双活：按客户或营业部把流量切到两端，单端故障切流秒级，配合前面说的同步复制，RPO=0 且 RTO 最小。代价是两端永远跑满配置，成本 2 倍，以及脑裂风险（下面细说）；
- 清算批量只能主备：批量任务读写同一份数据、抢同一批行锁，物理上只能一处跑。备端的价值是"主端批量机房故障时，备端重跑当日批量"——RTO 以小时计，因为重跑要先回滚半成品状态（《清算差错处理实战》的分级流程在这里复用）。
脑裂：双活最贵的故障
双活最怕的不是任何一端宕机，是两端之间的网络断了，各自都以为对方死了。同一客户的可用资金在两个端都被独立校验，理论透支风险直接翻倍。两道防线：
- 仲裁：独立的第三方仲裁节点（第三个机房的轻量服务，或共享存储投票）。一端失联时，由仲裁判定谁继续持有服务权——前提仲裁自己高可用，仲裁挂了比双活网络断了还麻烦；
- fencing（围栏）：被判定死亡的一端，在恢复联络前必须被剥夺服务能力——断电指令、存储写屏蔽、网络隔离，手段要狠。原则四个字：宁停勿双。短暂全停是事故，双写脑裂是案件。
演练真实性：纸面架构不等于可用架构
灾备方案最常见的自欺是"演练脚本预演了一万次"。脚本预演验证的是操作员的记忆，不是架构的可用性。真实演练要真刀真枪：流量真的切过去、在备端真的跑一整天交易、日终批量真的在备端跑一遍。真实切换才会暴露脚本永远碰不到的问题：DNS 和 VIP 缓存没刷新导致部分营业部连的是旧端、备端软件许可证按主机指纹签发切过去就失效、监控告警没跟着切走值班员看了旧端的绿屏。
考核 RTO 用真实演练的实测数据，设计值只配当目标。行业标准做法是每年至少一次完整切换，且要挑业务日历的空窗期之外——演练本身也是变更，要进变更日历（上一篇的管理体系在这里闭环）。
高可用架构的最后一块拼图永远是人：切换决策谁拍板、值班的人有没有权限执行 fencing、演练失败敢不敢上报。技术方案做到位之后，剩下的都是组织和纪律问题。