解读

面试官真正想验证的是：

1. 你是否把“切换”当成一次完整的“故障演练+数据核对”工程，而非单纯看监控曲线；
2. 能否把宏观的 RTO 拆成可量化的子阶段，并用压测手段把每个阶段“压”出边界；
3. 是否理解国内监管对“账务级一致性”的刚性要求（银保监、证监会、工信部指引），并能在测试里落地。
   一句话：既要让业务在“分钟级”内恢复，又要让账务在“零级”内不差钱。

知识点

1. 国标与行标：
   • JR/T 0204-2021《金融业多活数据中心通用规范》要求 RTO≤5 min，RPO≈0；
   • 工信部《分布式系统数据一致性测试方法》把一致性划分为强、单调、最终、无序四档。
2. 切换阶段拆解：
   故障探测→决策→流量调度→应用重连→缓存重建→数据对账→业务回切。
3. 压测工具组合：
   • 流量层：ChaosBlade 注入网络 300 ms 延迟/丢包，模拟机房级隔离；
   • 数据层：自研 SQL 探针在 MySQL/RDS 每 100 ms 采样 gtid/SCN，与对端比对；
   • 业务层：用 Gatling/JMeter 维持 80% 峰值 TPS，观察错误率与响应时间拐点。
4. 一致性量化指标：
   • 资金类：借贷平衡差额=0，幂等表无重复；
   • 订单类：库存超卖数=0，订单状态机无回退；
   • 消息类：生产端 successQ 与消费端 receivedQ 差值=0。
5. 统计方法：
   采用双样本 t 检验判断切换前后 5 min 内账务快照是否显著差异（α=0.01）。

答案

回答采用“三段式”：先给结论，再给方法，最后用数字证明。
“在现有多活架构下，我们把 RTO 拆成七段，通过故障演练+压测+对账三板斧，把 RTO 控制在 3 min 30 s，数据一致性达到账务级零差错。”

步骤如下：

1. 基线采样
   选工作日 20:00 高峰，用 Gatling 打 1.2 万 TPS（为历史峰值 1.5 倍），持续 30 min，记录各段耗时与资源水位，作为“切换基线”。

2. 故障注入
   用 ChaosBlade 对 A 机房出口交换机注入 100% 丢包，触发多活切换；同时保持压测流量不变，模拟“真高峰+真故障”。

3. 分段计时

   • 探测：Keepalived+BGP 收敛 18 s；
   • 决策：Raft 选主 5 s；
   • 调度：DNS 与 SLB 联动 25 s；
   • 重连：Druid 连接池超时重试 30 s；
   • 缓存：Redis 跨机房冷备重建 45 s；
   • 对账：批处理 90 s；
   • 回切：灰度验证 35 s。
     合计 248 s，满足 RTO≤5 min 要求。

4. 一致性核对
   在故障窗口内每 100 ms 抓取全局事务号，切换完成后 30 s 内完成三段对账：

   • 资金：总账-分户=0，差异笔数 0；
   • 订单：库存流水-库存余额=0，差异笔数 0；
   • 消息：RocketMQ 位点差=0，重复投递 0。
     采用 t 检验 p=0.008<0.01，无显著差异。

5. 结论
   通过 5 轮演练，RTO 稳定在 3 min 30 s±15 s，数据一致性 100%，满足监管“零差错”要求，并输出《多活切换性能报告》供运维与审计归档。

拓展思考

1. 如果业务允许“读多写少”，可引入“分层一致性”策略：写强一致、读最终一致，把对账时间窗拉长到 5 min，换取 RTO 降到 90 s。
2. 在两地三中心场景下，若使用跨 Region 的 PolarDB-X 或 OceanBase，需额外验证 Paxos 日志流跨城复制延迟，建议用“延迟预算”法：把 80% 延迟分布的上分位值计入 RTO，避免平均数掩盖长尾。
3. 监管现场检查常要求“可追溯”，因此测试报告必须包含：
   • 原始 pcap 包 SHA256；
   • 数据库 binlog 偏移量截图；
   • 性能测试脚本 Git commit id。
     提前准备好“审计证据链”，可让面试官感受到你对国内合规的敬畏与落地能力。