处理一次交易系统故障（如撮合引擎宕机），请描述故障排查流程和恢复策略。
上海证券交易所A03难度：困难
答案
1) 【一句话结论】
故障排查需遵循“快速定位-数据一致性验证-核心功能恢复-稳定验证”分阶段流程，恢复策略需覆盖主备切换、冷备启动，确保数据一致性与业务连续性。
2) 【原理/概念讲解】
老师口吻：交易系统中的撮合引擎是核心模块，负责订单匹配、成交确认等关键逻辑，好比交通枢纽的“调度中心”。当其宕机时，需按以下流程处理：
- 监控告警：通过Prometheus等平台实时采集CPU、QPS等指标，指标异常（如CPU 100%）触发告警，快速发现服务不可用。
- 日志分析：查看撮合引擎日志（如ELK），定位具体错误（如“数据库连接超时”），精准定位问题根源。
- 状态检查：通过API或管理界面确认服务状态（如“撮合引擎未启动”），判断是服务本身故障还是依赖资源（如数据库）问题。
- 数据一致性验证：检查数据库事务日志（如MySQL binlog），回滚未提交事务。例如，通过
mysqlbinlog -r -n -t 123456 binlog.000001回滚特定事务ID。 - 备份恢复：若数据损坏，使用备份快照（如MySQL的binlog备份）恢复数据。
类比：把交易系统比作交通枢纽，撮合引擎是核心调度中心，宕机时需快速切换备用调度中心（主备切换），同时疏导现有车辆（临时交易通道），确保核心交通（关键订单）优先恢复。
3) 【对比与适用场景】
| 对比维度 | 监控告警机制 | 日志分析流程 |
|---|---|---|
| 定义 | 通过指标（CPU、内存、QPS）触发告警，实时发现服务异常 | 通过日志（如ELK）分析错误堆栈、事务状态，深入定位具体问题 |
| 特性 | 实时性高，能快速响应故障初期（如服务不可用、资源耗尽） | 事后分析，能定位代码缺陷、配置错误等根本原因 |
| 使用场景 | 故障初期快速响应，如服务宕机、资源耗尽 | 故障后深入分析，如排查代码逻辑错误、配置错误 |
| 注意点 | 需设置合理阈值，避免误报（如CPU > 90%才告警） | 日志需结构化（如JSON），便于检索关键信息（如错误代码、事务ID） |
4) 【示例】
假设撮合引擎主节点（节点A）宕机，流程如下：
- 监控告警：Prometheus触发告警：“节点A CPU 100%，服务不可用”。
- 日志分析：节点A的ELK日志显示错误：“2023-10-27 10:00:01 ERROR com.shanghai.securities.matching.Engine: 数据库连接超时”。
- 状态检查：API检查节点A服务状态为“DOWN”，确认是服务未连接数据库（数据库服务正常）。
- 数据一致性验证：检查MySQL binlog，回滚未提交事务（事务ID为123456，命令：
mysqlbinlog -r -n -t 123456 binlog.000001）。 - 主备切换：通过ZooKeeper将备用节点B提升为主节点（命令：
zookeeperCli set /shanghai/securities/matching/leader B），切换后验证节点B的撮合功能（发送测试订单，检查成交结果正常）。 - 备用节点故障处理：若节点B也宕机，启动冷备节点C（从备份快照恢复数据，命令：
mysql -u root -p < backup.sql），验证数据一致性（比较主备节点数据），然后切换主节点为C。
伪代码（监控告警触发逻辑）：
def check_matching_engine_status():
cpu_usage = get_cpu_usage("撮合引擎A")
if cpu_usage > 90:
send_alert("撮合引擎A CPU过高，服务不可用")
service_status = check_service_status("撮合引擎A")
if service_status == "DOWN":
send_alert("撮合引擎A服务宕机")
5) 【面试口播版答案】
面试官您好，针对撮合引擎宕机的故障，我的处理流程是：首先通过监控平台（如Prometheus）快速发现告警，确认服务不可用；然后查看日志（如ELK）定位具体原因（如数据库连接超时）；接着检查数据库状态，回滚未提交事务（通过binlog回滚）；之后切换备用节点（主备切换），验证撮合功能；若备用节点故障，启动冷备节点（从备份恢复数据），最后通过压力测试（如JMeter模拟高并发）验证系统稳定性。整个过程遵循“快速定位-数据验证-核心恢复-稳定验证”的原则，确保数据一致性与业务连续性。
6) 【追问清单】
- 问题：如果备用节点也宕机了，怎么办？
回答要点：启动冷备节点（从备份快照恢复数据），或启用人工撮合通道处理紧急订单。 - 问题：故障期间如何保证数据一致性？
回答要点：通过数据库事务日志回滚未提交交易（如MySQL的binlog回滚特定事务ID），或使用备份快照恢复数据。 - 问题：恢复时间目标（RTO）和恢复点目标（RPO）如何设定？
回答要点：RTO通常设定为分钟级（如5分钟内恢复核心功能），RPO通过数据库备份频率设定（如每小时一次）。 - 问题：如果故障导致部分订单未成交，如何处理？
回答要点：通过订单重发机制（如重试队列）或人工干预（如客服处理）恢复未成交订单。
7) 【常见坑/雷区】
- 忽略数据一致性验证，直接重启服务导致未提交交易丢失。
- 恢复策略不分优先级，同时恢复所有功能导致核心功能延迟。
- 未考虑备用节点故障，仅依赖主备切换。
- 监控未设置关键指标告警（如撮合引擎的QPS告警），导致故障发现延迟。
- 主备切换流程不严谨，未验证状态同步或切换后功能正常。