一、故障恢复概述
大家好，我是老张。在量化交易这行摸爬滚打了十几年，今天咱们聊聊一个很要命的话题——故障恢复。
你可能觉得，系统稳定不就完了？干嘛非要搞故障恢复？
嗯，我年轻时也这么想。直到有一次，我们的交易系统在开盘前挂了，整整15分钟没起来。那15分钟，市场波动了0.3%，我们损失了大概...算了，不提了。从那以后，我彻底明白了：没有故障恢复的系统，就像没有安全气囊的跑车——跑得快，但撞了就完蛋。
为什么低延迟交易系统需要故障恢复？
说白了，原因就三个字：输不起。
你想想看，在低延迟交易里，毫秒级的停顿可能意味着几十万的损失。我见过最夸张的一次，某家机构因为网络抖动200毫秒，错过了最佳平仓时机，当天亏损超过800万。
具体来说，有这几个核心原因：
- 市场不等人——行情每秒都在变，系统挂了，机会就没了
- 合规要求——交易所和监管机构对系统可用性有硬性指标
- 声誉风险——一次重大故障，可能让客户对你失去信任
- 连锁反应——一个环节出问题，可能引发整个交易链的崩溃
核心观点：低延迟交易系统的故障恢复，不是"要不要"的问题，而是"必须做"的问题。它和低延迟本身同等重要。
核心指标：RTO 与 RPO
聊故障恢复，有两个指标你绕不开——RTO 和 RPO。
我习惯把它们比作"救火"和"补损失"：
| 指标 | 全称 | 定义 | 打个比方 |
|---|---|---|---|
| RTO | Recovery Time Objective | 系统从故障到恢复的最大可接受时间 | 救火队多久能到现场 |
| RPO | Recovery Point Objective | 可接受的数据丢失时间范围 | 火灾烧掉了多少文件 |
举个例子你就明白了。假设你的交易系统在10:00:00挂了，10:00:05恢复：
- 如果RTO是3秒，那你就超时了——系统恢复花了5秒，不合格
- 如果RPO是1秒，那10:00:00到10:00:01之间的数据丢了，你得接受
我的经验：在低延迟交易场景下，RTO通常要求控制在毫秒级，RPO则尽量做到零丢失。但说实话，零丢失很难，成本太高。我个人习惯的做法是：核心交易链路RPO=0，辅助系统RPO可以放宽到几秒。
故障恢复的黄金法则
做了这么多年，我总结出三条黄金法则。嗯，你可以把它当成"保命三招"：
- 预防优于恢复
别等出事了再想办法。我曾经在系统里埋了上百个监控点，每天自动巡检。有一次凌晨3点，监控发现某个内存池异常增长，自动触发了预恢复流程。等运维早上到公司，问题已经解决了。这就是预防的力量。
- 恢复路径要可预测
故障发生时，别让系统"自由发挥"。我见过最坑的案例：某系统挂了之后，自动切换到了备用节点，但备用节点本身也有问题，结果两个节点一起崩。后来我们规定：恢复路径必须提前定义好，并且定期演练。
- 速度与一致性要平衡
你想想看，恢复得太快，可能数据还没同步完；恢复得太慢，市场机会就没了。这个平衡点怎么找？我的做法是：分层恢复——先恢复核心交易能力，再慢慢补数据。
避坑指南：我曾经犯过一个错误——为了追求极致的恢复速度，把数据同步改成了异步模式。结果有一次主节点挂了，备用节点少了3秒的数据，导致一笔交易的价格错了。从那以后，我坚持核心数据必须同步复制，哪怕慢一点。
知识体系总览
下面这张图，是我对故障恢复知识体系的梳理。你可以把它当成整个课程的"地图"：
这张图展示了故障恢复体系的三个核心支柱：预防机制、检测与告警、恢复执行。它们环环相扣，缺一不可。而RTO和RPO，则是衡量整个体系好坏的标尺。
小结
好了，第一章就聊到这儿。总结一下今天的内容：
- 低延迟交易系统必须做故障恢复，因为输不起
- RTO管的是恢复速度，RPO管的是数据丢失量
- 黄金法则：预防 > 恢复、路径可预测、速度与一致性平衡
下一章，我会带你深入聊聊故障检测与告警机制——怎么在故障发生的第一时间就发现它，而不是等用户投诉了才知道。咱们到时候见。