双机热备：让云服务器上的量化交易系统永不停机（实战部署教程）

双机热备：让云服务器上的量化交易系统永不停机（实战部署教程）

这篇教程帮你解决什么问题： 量化策略跑在单台云服务器上，最怕的就是服务器宕机、系统崩了或者自己手贱把环境搞坏——策略停机的每一分钟都可能在亏钱。跟着这篇做完，你会有两台服务器组成主备架构：主机挂了，备机 30 秒内自动接管策略，持仓数据不丢，你甚至可以在睡梦中完成切换。整套方案用开源软件实现，两台低配服务器的成本一天不到两块钱。

腾讯云促销活动：https://www.tencentcloud.com/act/pro/QuantSolution?lang=zh&fromSource=intl.17760459.17760459.17760459

先说清楚，这篇是给策略已经稳定盈利、开始对"停机"这件事肉疼的人看的。如果你的策略还在回测阶段，先收藏，别急着折腾。

我入坑量化快四年，前两年都是单机跑策略，心态很佛系：挂了重启呗，反正频率不高。

转折发生在今年 3 月。

那天晚上 11 点多，我准备给服务器升级个 Python 包，apt upgrade 顺手带上了，结果一个底层库版本冲突，直接把行情接口的动态链接库搞挂了。等我把环境修好，已经是凌晨 1 点半。期间夜盘完全没法交易，更要命的是，第二天早盘我用了一个小时核对仓位状态，生怕停机期间数据对不上。

两个半小时，就因为我手贱敲了一行 apt upgrade。

那晚我在床上翻来覆去，想明白了一件事：我不是缺技术，我是缺"随便折腾也不怕"的底气。单机跑策略，服务器就是单点故障，你敢升级系统吗？不敢。你敢重启吗？心虚。这种状态太憋屈了。

第二天我就开始研究双机热备。

一、旧方案的单点故障有多憋屈

单机跑策略的那两年，我把自己活成了服务器的保姆：系统不敢升级（怕依赖冲突）、配置不敢乱改（怕改错起不来）、每个月还得手动备份一次数据库到本地（有两次还忘了）。3 月那次事故之前，我最长的"不敢重启服务器"记录是 147 天——不是服务器稳，是我不敢。147 天没打安全补丁，想想都后怕。单机方案省下的那点钱，最后都变成了提心吊胆。

说白了，单机架构下，你不是在跑量化，你是在供着一台祖宗。

二、双机热备的思路：别想复杂了，就是"一个干活一个待命"

一开始我研究过 K8s、研究过负载均衡集群，越看越晕——那是给互联网公司玩的东西，我一个跑三个策略的个人玩家，用得着吗？

后来想通了，我的需求其实特别朴素：

1. 主机正常干活，备机在旁边同步数据、随时待命
2. 主机挂了，备机自动顶上，不用我半夜爬起来操作
3. 两套环境的策略配置必须一模一样，切换后行为一致

对应到技术方案就三个组件：

• 两台腾讯云轻量应用服务器（我都用的 2核2G Ubuntu，策略不重，够跑）
• Keepalived：做主备健康检测和自动切换，主的心跳没了，备的立刻宣布"我来接管"
• 数据同步：持仓和状态数据实时从主同步到备，我用的方案是策略状态每 5 秒写一次 Redis，Redis 开主从复制

没有共享存储，没有分布式文件系统，就这么简单。量化策略的热备，难点从来不在切换，而在状态数据的一致性。

三、部署过程：一个下午搞定

周六下午，我开了第二台轻量服务器。两台机器放在同一地域，内网互通，延迟不到 1ms。

第一步，把主机的整个策略环境复制到备机。我图省事，直接在腾讯云控制台给主机做了个自定义镜像，然后用镜像开了备机——环境、依赖、配置 100% 一致，这步只用了 10 分钟。比自己写 Dockerfile 或者 Ansible 脚本快多了。

第二步，装 Keepalived。两边都是一行：

apt install keepalived -y

主机配置（/etc/keepalived/keepalived.conf）核心是这几行：

vrrp_instance QUANT {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass quant88
    }
    virtual_ipaddress {
        10.0.x.100   # 内网虚拟IP
    }
}

备机配置几乎一样，就两处不同：state BACKUP，priority 90。

虚拟 IP（VIP）是整个方案的精髓：我的行情接入、告警推送，全都连这个 VIP，而不是具体某台机器的 IP。 VIP 平时漂在主机上；Keepalived 每秒检测一次心跳，主机失联，备机 1-3 秒内把 VIP 抢过来，自动接管。

第三步，Redis 主从。主机上 Redis 正常跑，备机的 redis.conf 里加一行：

replicaof 10.0.x.10 6379

策略那边改动的唯一地方是：每 5 秒把关键状态（持仓、当日盈亏、已处理信号列表）写进 Redis。这个改动大概花了我一个小时。

全部搞完，傍晚 6 点。中间还吃了个饭。

四、第一次切换演练：手心冒汗的 30 秒

配置完不能直接用，得演练——不演练的灾备方案等于没有。

周日早上 9 点，我泡了杯茶，坐在电脑前，深吸一口气，在主机上敲了：

systemctl stop keepalived

模拟主机故障。

然后我盯着备机的日志。大概 2 秒，备机 Keepalived 打印 Entering MASTER STATE，VIP 漂移成功。我跑到备机上手动拉起策略（这一步后面我做了自动化），策略读 Redis 里的最新状态，持仓、信号断点全部对得上。

从"主机挂"到"备机接管策略继续跑"，全程 30 秒左右。

那杯茶我喝得特别香。两年了，我第一次有"随便折腾，反正有备份"的感觉。

对比 3 月那次事故：单机挂了，我修环境修了 2 个半小时，还花 1 小时核对仓位。现在同样的事故，30 秒自动切换，仓位状态分毫不差。这买卖怎么算都值。

五、也踩了一个小坑：脑裂，两台机器同时觉得自己是老大

热备上线第三周，我踩了这个方案里最经典也最危险的坑：脑裂（Split-Brain）。

那天下午机房网络抖动（事后看云厂商状态页确认的），两台服务器内网断开了大概 40 秒。Keepalived 的机制是"收不到主的心跳我就上位"，于是备机果断把 VIP 抢了——但主机其实活得好好的，策略还在跑！

结果就是灾难性的：两台机器同时认为自己是主，同一个账户，两边同时下单，重复成交了 4 笔。 我事后手动平仓对冲，亏了小几百块手续费+滑点。

痛定思痛，我加了两道保险：

1. 第三方仲裁：策略下单前，先访问一个外部接口（我用的是自己监控服务器上的一个简单 HTTP 服务）确认"我是合法的主机"。两台机器能互通但一起连不上外部的概率，比单纯内网断连低几个数量级。
2. 交易所层兜底：能设 client order id 前缀的接口，主备用不同前缀，券商端能看到重复下单时我可以第一时间发现。

改完之后又演练了三次各种断网场景，再没有出过重复下单。

所以这里给大家的忠告是：双机热备最难的从来不是"切换"，而是"防止两边都活"。脑裂防护不做，热备比单机还危险。

六、数据同步的分寸：什么该同步，什么别同步

再多说一句实战经验。不是所有数据都值得实时同步：

• 必须实时同步：持仓、当日已成交列表、已处理信号 ID（防止备机重复触发）、策略运行断点
• 不需要同步：历史 K 线（备机自己重新下载就行）、日志（各记各的）、回测数据

我一开始犯过完美主义的错，想把主机的整个 MongoDB 历史库都实时同步到备机，结果同步流量把 2核2G 小机器的内网带宽占得满满的，策略都变卡了。后来砍到只同步 Redis 里的状态数据，每 5 秒几 KB，毫无压力。

热备保的是"业务连续性"，不是"数据完整性"。 历史数据定期备份就够了，别塞进实时同步链路里。

七、还能更好的地方

1. 备机接管策略目前还要我脚本里兜底拉起，极端情况下（主备同时挂）还是得人工介入。当然两台一起挂的概率，跟我中彩票差不多。
2. 切换那一刻如果有在途委托，需要策略重新查询委托状态做一次对账，这段逻辑我写了 100 多行，是整个方案里最烧脑的部分。
3. 腾讯云轻量服务器的内网 VIP 需要在控制台做绑定配合，第一次配的时候对着文档研究了一阵子。不过配一次就不用管了。

这些都是工程细节，不影响方案的整体价值。

八、总结

一句话：策略开始赚钱之后，双机热备不是成本，是保险——而且是那种你绝对不想用到、但必须有理赔能力的保险。

给不同阶段玩家的建议：策略日盈利还覆盖不了一台服务器钱的，先单机跑，把精力放在策略上；策略稳定盈利、开始"停机肉疼"了，直接抄这篇作业，两台 2核2G 轻量服务器+Keepalived+Redis 主从，一个下午搞定。但脑裂防护那一节，请逐字看完再动手——这是我花真金白银买的教训。

腾讯云促销活动：https://www.tencentcloud.com/act/pro/QuantSolution?lang=zh&fromSource=intl.17760459.17760459.17760459

常见问题 FAQ

Q：个人量化有必要做双机热备吗？

看策略类型和资金规模。高频、隔夜持仓、或者停机一天亏损超过两台服务器一年成本的，必须做。低频日线策略、小资金试水的，单机+定时备份就够了。

Q：双机热备用什么软件实现？

主流方案是 Keepalived 做 VIP 漂移和主备切换，配合 Redis 主从复制同步策略状态数据。个人量化场景不需要 K8s 这类重型方案，两个开源软件加一个下午就能搭完。

Q：两台云服务器做主备，配置需要一样吗？

建议完全一样，最好直接用主机的自定义镜像开备机，保证 Python 环境、依赖库版本、策略配置 100% 一致。环境不一致的"备机"，切换后可能跑不起来或者行为异常。

Q：什么是脑裂？怎么防止？

脑裂是指主备之间网络断开后，两台服务器都认为自己是主机，导致同一账户重复下单。防护办法：下单前引入第三方仲裁（访问外部接口确认身份）、主备使用不同的委托 ID 前缀便于发现重复单。

Q：双机热备需要多少成本？

两台 2核2G 的腾讯云轻量应用服务器，加起来一天不到两块钱。相比单机宕机一次造成的仓位混乱和行情错失，这个成本基本可以忽略。