2、恢复基础：什么是恢复？RTO与RPO的概念
大家好，我是你们的讲师。今天我们来聊聊恢复这件事。
说实话，很多做量化交易的朋友，一开始都不太重视恢复。大家更关心策略怎么写、回测怎么做、延迟怎么降。但我要说，恢复机制才是交易系统的最后一道防线。你想想看，系统崩了不可怕，可怕的是崩了之后不知道怎么办。
什么是恢复？
恢复，说白了就是系统出问题之后，怎么让它重新跑起来。
我遇到过不止一次这样的情况：凌晨三点，交易系统突然挂了。订单发不出去，行情收不到，整个团队手忙脚乱。这时候你需要的不是写代码，而是有一套明确的恢复流程。
恢复包含两个层面：
- 系统恢复：让程序重新运行起来
- 数据恢复：把丢失的数据找回来
嗯，这里要注意，两者缺一不可。系统跑起来了但数据丢了，等于白干。数据都在但系统起不来，也是白搭。
RTO：恢复时间目标
RTO，全称是 Recovery Time Objective。翻译成人话就是：系统挂了之后，你最多能容忍它挂多久。
举个例子：
- 高频交易系统：RTO 可能只有几秒钟
- 日内策略系统：RTO 可能是几分钟
- 盘后分析系统：RTO 可能是几小时
我个人的习惯是，先问业务团队一个问题：「系统停多久你会想骂人？」
这个答案，就是你的 RTO。
核心要点：RTO 决定了你的恢复方案要花多少钱、投入多少资源。
RPO：恢复点目标
RPO，全称是 Recovery Point Objective。说白了就是：你能接受丢多少数据。
我记得有一次，一个团队的数据库挂了。他们用的是每小时备份一次的策略。结果系统在备份后第59分钟崩溃了，丢了将近一小时的交易数据。那个月，他们被客户投诉了十几次。
RPO 的常见场景：
| 业务类型 | RPO 要求 | 说明 |
|---|---|---|
| 订单系统 | 0（零丢失） | 丢一个订单都可能造成巨大损失 |
| 行情系统 | 几秒钟 | 行情数据可以容忍短暂丢失 |
| 风控系统 | 毫秒级 | 风控数据必须实时同步 |
| 日志系统 | 几分钟 | 日志丢了可以补，影响不大 |
避坑指南：我曾经见过一个团队，RPO 设成了「零丢失」，但备份方案用的是每天一次全量备份。你想想看，这怎么可能实现零丢失？RPO 和备份策略必须匹配，否则就是纸上谈兵。
RTO 和 RPO 的关系
这两个指标不是独立的。它们就像跷跷板的两头：
- RTO 越小，需要的冗余资源越多，成本越高
- RPO 越小，备份频率越高，存储成本越大
我建议的做法是：先定 RTO，再定 RPO。因为恢复时间往往比数据丢失更致命。系统挂了十分钟，可能已经错过了最佳交易时机。数据丢了几秒钟，反而可以通过其他渠道补回来。
如何确定你的 RTO 和 RPO？
这里分享一个我常用的方法：
- 列出所有核心业务：订单、行情、风控、清算...
- 评估每个业务的容忍度：停多久会出问题？丢多少数据会出事？
- 计算成本：实现这个 RTO/RPO 需要多少钱？
- 做取舍：如果成本太高，适当放宽要求
举个例子，我参与过的一个项目：
业务：高频做市系统
RTO：5秒（超过5秒，做市商资格可能被取消）
RPO：0（订单数据不能丢）
方案：双活数据中心 + 实时同步 + 自动切换
成本：每年多花200万你看，这个 RTO 和 RPO 要求很高，但业务价值也高。如果换成普通的量化策略系统，可能 RTO 设成5分钟就够了，成本能省一大半。
恢复策略的选择
根据 RTO 和 RPO 的不同，恢复策略也不一样：
- 冷备：RTO 几小时，RPO 几小时。适合非核心系统
- 温备：RTO 几分钟，RPO 几分钟。适合日常交易系统
- 热备：RTO 几秒，RPO 零。适合高频交易系统
我个人比较推荐温备方案。为什么呢？因为热备太贵，冷备太慢。温备在成本和性能之间找到了一个平衡点。当然，如果你的业务真的需要毫秒级恢复，那热备是唯一选择。
知识体系总览
下面这张图，帮你理清 RTO 和 RPO 的核心逻辑：
小技巧：刚开始做恢复设计时，别追求完美。先定一个你能实现的 RTO 和 RPO，然后逐步优化。我见过太多团队一开始就想做到「零丢失、零延迟」，结果方案太复杂，反而更容易出问题。
好了，这一章的内容就到这里。记住一句话：恢复不是事后补救，而是事前设计。你的 RTO 和 RPO 定好了，恢复方案就有了方向。
公众号:蓝海资料掘金营，微信deep3321