第24章灾难恢复与业务连续性

第24章：灾难恢复与业务连续性：主备切换、数据备份、异地容灾、演练计划

做市商系统，说白了就是一台24小时不停转的印钞机。但印钞机也会坏，机房可能断电，光纤可能被挖断，甚至整个城市都可能遭遇不可抗力。我见过太多团队，平时觉得灾备是浪费钱，真出事了才追悔莫及。

这一章，咱们就聊聊怎么让系统在灾难面前「扛得住、切得走、回得来」。

24.1 主备切换：别让切换比故障更可怕

主备切换，听起来简单——主节点挂了，备节点顶上。但实际操作中，我踩过的坑比想象中多得多。

24.1.1 主备架构的三种模式

模式	切换时间	数据一致性	适用场景
冷备	分钟级	可能丢失	非核心模块
温备	秒级	基本一致	订单系统
热备	毫秒级	强一致	行情、风控

我个人习惯，核心交易链路必须用热备。为什么？因为做市商每秒都在亏钱。你想想看，行情断了10秒，你的报价可能已经偏离市场几个tick了。

24.1.2 切换的「三把斧」

我建议每个团队都准备好这三样东西：

健康检查脚本：每5秒探测一次，连续3次失败就触发切换
切换决策表：明确什么情况下自动切，什么情况下手动切
回退预案：切过去之后，怎么切回来？这个很多人会忘

核心原则：宁可切错，不可不切。自动切换的阈值可以设得宽松一些，人工确认反而会耽误时间。

24.2 数据备份：你的命根子

做市商的数据有多值钱？订单簿、成交记录、持仓数据，随便丢一天，审计就能让你吃不了兜着走。

24.2.1 备份策略的「3-2-1」法则

这个法则我用了十年，从来没出过问题：

3份副本：生产环境1份，备份环境2份
2种介质：SSD+磁带，或者SSD+云存储
1份异地：至少有一份放在不同城市

24.2.2 增量备份 vs 全量备份

全量备份太慢，增量备份恢复太复杂。我的做法是：

# 每天凌晨2点执行
# 周一：全量备份
# 周二~周日：增量备份
# 保留最近30天的备份

# 备份脚本示例
#!/bin/bash
BACKUP_DIR="/data/backup/$(date +%Y%m%d)"
if [ $(date +%u) -eq 1 ]; then
    # 周一全量
    pg_dump -Fc trading_db > $BACKUP_DIR/full.dump
else
    # 其他天增量
    pg_dump -Fc --schema-only trading_db > $BACKUP_DIR/schema.dump
    pg_dump -Fc --data-only --exclude-table=history trading_db > $BACKUP_DIR/data.dump
fi

避坑指南：我曾经遇到过备份文件损坏的情况，原因是磁盘满了。从那以后，我每次备份完都会做一次校验，用md5sum比对源文件和备份文件的哈希值。

24.3 异地容灾：别把鸡蛋放在一个篮子里

同城双活？遇到地震、洪水一样完蛋。真正的容灾，必须跨城市，甚至跨区域。

24.3.1 异地容灾的三种级别

级别	RPO	RTO	成本
L1 数据级	1小时	4小时	低
L2 应用级	15分钟	30分钟	中
L3 业务级	秒级	分钟级	高

做市商至少要做到L2。为什么？因为RPO（恢复点目标）决定了你会丢多少数据，RTO（恢复时间目标）决定了你会停多久。这两个数字，直接换算成钱。

24.3.2 数据同步的「最后一公里」

异地同步最大的坑是延迟。上海到深圳，光纤来回也要30毫秒。对于高频做市来说，这30毫秒足够让行情变几个来回。

我的解决方案是：

异步复制：主库写本地，通过消息队列同步到异地
最终一致性：允许短时间的不一致，但保证最终能追上
冲突处理：以主库时间戳为准，备库的冲突数据直接丢弃

注意：千万不要用同步复制做异地容灾。网络抖动一次，整个交易链路就卡住了。我见过有人这么干，结果一次光纤抖动，全系统停了3分钟。

24.4 演练计划：平时多流汗，战时少流血

很多团队的灾备方案写得漂漂亮亮，真到演练的时候，各种问题就冒出来了。我建议每季度至少做一次全流程演练。

24.4.1 演练的四个阶段

桌面推演：会议室里过流程，确认每个人知道自己该干什么
功能验证：在测试环境模拟故障，验证切换脚本是否正常
压力测试：在生产环境的低峰期，模拟真实流量下的切换
复盘总结：记录所有问题，更新预案

24.4.2 演练的「三个必须」

根据我的经验，演练中必须做到：

必须断真网：别只是kill进程，要真的拔网线或者关交换机
必须测回切：切过去不算完，切回来才是真本事
必须留记录：每一步操作、每个异常、每次耗时，都要记下来

我的习惯：每次演练后，我会把发现的问题整理成「灾备问题清单」，贴在团队墙上。下次演练前，先检查这些问题是否已经修复。

24.5 核心架构图：灾难恢复全景

下面这张图，是我做灾备架构时必画的。它把主备切换、数据备份、异地容灾、演练计划串在了一起。

这张图的核心逻辑是：主站点负责日常交易，数据异步同步到备站点。备份层做全量和增量备份，并异地存储。演练计划定期验证整个链条是否通畅。

24.6 最后说几句

灾难恢复这件事，说白了就是「用钱换时间」。你愿意花多少钱，就能在多短的时间内恢复。但有一点要记住：再贵的方案，也比不上一次真实的演练。

我见过最惨的案例，是一家做市商花了几百万做灾备，结果演练的时候发现备库的磁盘阵列是坏的。嗯，这种错误，一次都不能犯。

我的建议：从今天开始，给你的灾备方案定一个「最低标准」——至少保证核心交易链路能在15分钟内恢复，数据丢失不超过1分钟。其他的，慢慢优化。

无相订单流研究社微信Lucian808555

📚 课程目录