量化交易机器人断线重连怎么做？云服务器守护进程配置实战指南

量化交易机器人断线重连怎么做？云服务器守护进程配置实战指南

先说结论：这篇教程帮你解决"量化交易程序半夜挂了、断线了没人管"的问题。跟着做一遍，你会得到一个跑在云服务器上、崩了自动拉起、断电重启后自动恢复、断网重连后自动补行情的机器人，实测挂了 17 次全都自己爬起来了。

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

我是从去年开始跑实盘的，一个做期货日内的 CTA 策略，用 Python 写的，之前一直挂在家里一台吃灰的旧笔记本上。

上个月某天早上醒来，打开行情软件一看——持仓没平，策略早就不动了。

一看日志：凌晨 2 点 40 分，行情连接断了，进程没崩，但行情流停了，程序就这么干挂着，像个植物人一样躺了六个多小时。那一单最后少赚了 2000 多。

我当时心里就俩字：不行。

家里宽带会抖、笔记本会休眠、Windows 会半夜偷偷更新重启，这种环境跑量化交易，迟早出事。那天晚上我一咬牙，把整套东西搬到了腾讯云轻量应用服务器上，顺手把守护进程也配了。

结果这一个多月，程序崩过 3 次、断网重连过十几次，没有一次需要我人工介入。睡到自然醒，账户一切正常。

索性把整套方案整理出来，给同样被"半夜断线"折磨过的朋友。

一、先说清楚：你的程序为什么会"死而不僵"

很多人以为程序崩了就是退出了，其实量化交易程序最常见的死法根本不是崩溃，而是这三种：

1. 行情连接断了但没退出：进程还在，行情不来了，单子发不出去
2. 程序卡死：某个第三方库死锁，CPU 占用 0%，日志不滚动
3. 真崩溃：Python 抛异常退出了，这个最好处理

我那个凌晨 2 点的事故就是第一种。本地电脑上你只能自认倒霉，但在云服务器上，这些问题有一套成熟的组合拳：守护进程保活 + 程序内重连 + 心跳检测。

之前我在家里笔记本上是怎么"解决"的？设了个手机闹钟，凌晨 1 点、3 点、5 点各响一次，爬起来瞄一眼程序还活着没。坚持了一个礼拜，人快神经衰弱了。还试过 Windows 的任务计划程序定时重启，结果有一次重启的时候正好持仓，差点搞出事故。

二、上云：为什么是轻量应用服务器

当天晚上的决策过程很简单：我需要一个 7×24 小时开机、网络稳定、别太贵的地方跑一个 Python 进程。

对比了一圈，选了腾讯云轻量应用服务器，2 核 2G 的 Ubuntu 22.04，一天不到一块钱。下单到拿到 IP 密码不到两分钟，SSH 连上去就是一台干净的 Linux 机器。

说个实话，我之前用过某家海外 VPS，便宜是真便宜，但晚高峰延迟能飘到 300ms，行情数据慢半拍，做日内的根本没法用。腾讯云轻量这台，到交易所托管机房的延迟基本稳定在个位数毫秒级别——虽然咱们做量化的不像高频那么吃延迟，但行情不卡顿是最基本的尊严。

代码传上去，装依赖：

sudo apt update && sudo apt install -y python3-pip python3-venv
python3 -m venv ~/venv
source ~/venv/bin/activate
pip install -r requirements.txt

十分钟，程序在云服务器上跑起来了。但这只是第一步——裸跑的程序和家里笔记本没本质区别，重点在下面。

三、systemd 守护进程：崩了自己爬起来

Linux 下做守护进程，别折腾 supervisor 了，系统自带的 systemd 就是干这个的，一行额外软件都不用装。

我新建了一个服务文件：

sudo vim /etc/systemd/system/quant-bot.service

内容长这样，每一行我都加了注释：

[Unit]
Description=Quant Trading Bot
# 等网络就绪再启动，避免开机时连不上行情
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=ubuntu
WorkingDirectory=/home/ubuntu/quant-bot
ExecStart=/home/ubuntu/venv/bin/python main.py
# 不管怎么死的，都重启
Restart=always
# 重启前等5秒，别疯狂刷屏
RestartSec=5
# 10分钟内重启超过5次就放弃，防止代码有bug死循环
StartLimitIntervalSec=600
StartLimitBurst=5

[Install]
WantedBy=multi-user.target

然后三条命令让它生效：

sudo systemctl daemon-reload
sudo systemctl enable quant-bot   # 开机自启
sudo systemctl start quant-bot    # 现在启动

配完我干了一件很解压的事：手动把进程杀掉，看它能不能复活。

ps aux | grep main.py     # 找到 PID
kill -9 <PID>             # 暴力杀掉
sleep 6
systemctl status quant-bot  # 查看状态

屏幕上赫然显示 active (running)，日志显示进程在 5 秒后被重新拉起。

那一刻真的有点爽。以前家里那台笔记本上程序死了就是真死了，现在是打不死的小强。

查日志也方便：

journalctl -u quant-bot -f        # 实时看日志
journalctl -u quant-bot --since today  # 看今天的

四、程序内的断线重连：光保活还不够

systemd 解决的是"进程退出"，但前面说了，量化交易程序最常见的死法是进程活着、行情死了。这种情况 systemd 看不出来，必须在程序里加心跳。

我的做法很简单：每次收到行情 tick，就更新一个时间戳；另起一个线程每 30 秒检查一次，超过 90 秒没收到行情，就主动重连。

import time, threading

class Watchdog:
    def __init__(self, reconnect_func, timeout=90):
        self.last_tick = time.time()
        self.reconnect = reconnect_func
        self.timeout = timeout
        threading.Thread(target=self._loop, daemon=True).start()

    def feed(self):
        self.last_tick = time.time()   # 每来一个tick就喂一次

    def _loop(self):
        while True:
            time.sleep(30)
            if time.time() - self.last_tick > self.timeout:
                print("[Watchdog] 行情超时，触发重连")
                self.reconnect()
                self.last_tick = time.time()  # 重置，给它一次重连机会

在行情回调函数里调 watchdog.feed() 就行。

这里有个量化交易特有的细节：夜盘结束、节假日、盘中休市的时候，本来就没行情，别把心跳超时设成 30 秒然后中午 11 点半到 1 点半疯狂重连。我的处理是策略里维护一个"交易时段表"，非交易时段看门狗直接休眠。

五、踩坑：重启太勤快，差点被行情服务器拉黑

说到这儿必须坦白一个我踩过的坑，也算是这篇文章最值钱的部分。

刚配好那两天，我把心跳超时设得特别激进——60 秒没行情就重连。结果有天下午网络抖动，重连了失败，失败了重连，一分钟内重连了 8 次，然后行情服务器直接把我踢了，返回一个错误码，意思是"登录过于频繁"。

更惨的是，被踢之后我的重连逻辑还在疯狂重试，越踢越试，越试越踢，恶性循环了十几分钟。

后来怎么解决的？给重连加退避策略：

def reconnect_with_backoff(self):
    delay = 5
    for attempt in range(6):
        try:
            self.connect()
            return
        except Exception as e:
            print(f"重连失败，{delay}秒后重试: {e}")
            time.sleep(delay)
            delay = min(delay * 2, 300)   # 5,10,20,40,80...最多5分钟

就是经典的指数退避：第一次等 5 秒，第二次 10 秒，翻倍涨，封顶 5 分钟。改完之后这一个多月，最长的一次断线（运营商线路问题，断了 4 分钟）也平滑恢复了。

所以给大家一个建议：重连逻辑一定要带退避，没有退避的重连比不重连更危险。

六、断电重启演练：服务器重启后会自己回来吗

最后一个验证：云服务器本身重启了怎么办？

我直接在控制台点了重启，然后去倒了杯水。回来一看：

• 服务器启动后 systemd 自动拉起 quant-bot（因为设了 enable）
• 程序启动后自动登录行情和交易接口
• 看门狗进入工作状态

全程零人工干预。从服务器开机到策略恢复运行，不到 1 分钟。

相比之下，以前家里笔记本如果断电，我得：开机 → 输密码 → 开行情软件 → 开终端 → 激活虚拟环境 → 启动程序，中间任何一步忘了就完犊子。

七、成本和新旧方案对比

这套东西跑在 2 核 2G 的腾讯云轻量应用服务器上，CPU 平时占用 5% 不到，内存吃了 600M 左右，一天不到一块钱的成本。

八、总结：跑实盘的人，先把"命"保住

量化交易这行有句话：策略再好，执行掉链子等于零。我那个凌晨 2 点的教训告诉我，基础设施的可靠性比策略优化重要一个数量级——策略从年化 20% 优化到 25% 很难，但把"半夜挂机"这个风险干掉，只需要一个晚上的时间。

我的建议是：

• 还在本地跑实盘的朋友：别等了，今晚就搬。systemd 那一节照抄，半小时搞定，从此告别凌晨闹钟。
• 完全没碰过 Linux 的小白：这篇里的命令不多，每一步都给了完整命令，跟着敲就行。唯一要记住的是 systemctl status 和 journalctl -u quant-bot -f 这两条，出问题先看日志。
• 已经在云上跑但没配守护的：你现在就是裸奔，赶紧把第三节的服务文件抄走。

放心冲。这套组合我已经实盘跑了一个多月，稳得一批。

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

常见问题 FAQ

Q：云服务器跑量化程序断网了怎么办？

分两层处理：进程层面用 systemd 的 Restart=always 保活，崩了自动拉起；网络层面在程序里加心跳看门狗，超过 90 秒没行情就触发重连，重连要带指数退避（5 秒起步翻倍，封顶 5 分钟），避免被行情服务器判定频繁登录。

Q：systemd 和 supervisor 选哪个？

新手直接用 systemd。它是 Ubuntu 自带的，不用装任何东西，Restart=always 加 RestartSec=5 两行就实现了守护，开机自启也是一条 systemctl enable 的事。supervisor 功能更多但要额外安装配置，单机跑一两个程序用不上。

Q：程序没崩溃但行情不来了，systemd 不会重启它，怎么办？

对，这种情况 systemd 无能为力，必须在程序内部检测：记录最后一次收到行情的时间戳，另起线程定期检查，超时就在程序内主动断开重连。注意要判断交易时段，休市时间别误触发。

Q：2 核 2G 的云服务器够跑量化交易吗？

跑单策略实盘足够。我自己的 CTA 策略加上行情接收、下单、日志，CPU 常年 5% 以下，内存 600M 左右。除非你要同时跑高频或者本地存大量历史数据回测，否则不用加配置。

Q：quant-bot 重启后持仓状态会不会丢？

会，这是个好问题。建议程序启动时先调用交易接口查询当前持仓和挂单，用查询结果恢复内部状态，而不是假设自己是空仓启动。重启恢复逻辑要在实盘前专门测试一遍。