量化交易系统中的跨交易所对冲策略：从原子化撮合到分布式执行
TL;DR
跨交易所对冲（套利）听起来像“同时买/卖两边吃价差”，但工程现实是：你在和端到端延迟、双腿下单缺乏原子性、高并发状态竞争、以及交易所 API 异构四件事掰手腕。想把脚本升级成可长期运行的系统，关键不是“更聪明的策略”，而是把链路拆成：行情网关（统一范式）→ 策略引擎（信号生成）→ 执行网关（并发下单 + 限频 + 订单生命周期）→ 风控/仓位中台（资金与敞口的唯一真相）。在无法做 2PC 的前提下，用 SAGA 把“伪原子性”落地：一腿成功另一腿失败时立刻触发补偿平仓，并用监控与告警把“烂尾单”从事故变成可控成本。
关键要点与工程坑点
- 延迟不是“优化点”，是物理约束：传播延迟（光纤光速）、设备排队/转发、TLS 加解密、TCP 握手都会吞掉套利窗口；优先做长连接（WebSocket/Keep-Alive）、禁用 Nagle（
TCP_NODELAY）、严格超时与就近部署（Co-location）。 - 双腿下单无法严格原子：交易所不提供
prepare，2PC 不存在；正确做法是承认“不可能”，把风险显式化，用 SAGA 的补偿动作（反向单平仓）把最坏情况控制在可接受范围内。 - 补偿本身也可能失败：交易所宕机/限频/网络抖动都可能让“平仓单”失败——这类场景必须触发最高级别告警，并准备人工/交易员介入流程。
- 订单类型是风险权衡：限价单能控滑点但可能不成交；市价单保证成交但可能吞噬利润；常见折中是 IOC/FOK（能成交就成交，不能就撤）。
- Rate Limit 与并发资金争抢：多个策略并发下单会抢同一笔资金/仓位额度；需要“风控/仓位中台”做前置预算与原子扣减（或乐观锁 + 重试），执行网关按交易所维度做限频/排队。
- 统一适配层（Adapter）是首要工程资产：把 WebSocket/REST、字段、错误码、重连/心跳、签名鉴权封装在适配层之下，上层只看统一的行情/订单模型，避免业务代码被 API 细节污染。
- 反压（Backpressure）必须设计：行情永远可能“比你处理得快”；通道（channel/queue）满了怎么办？丢弃、采样、降频、或分层缓存要提前定义，否则系统会用阻塞把你拖死。
- 可观测性决定你能不能睡觉：关键指标至少包括：各段延迟、下单成功率、API 错误码分布、烂尾单数量、补偿成功率、单边敞口、连接状态与重连次数。
适用场景
- 跨交易所对冲/套利执行系统：不讨论策略有效性，专注在稳定地把信号变成“可控风险的成交”。
- 多交易所行情聚合与统一交易接口：需要统一数据范式与标准化订单生命周期管理的团队。
- 从单机脚本演进到分布式：当监控标的/交易所/交易对扩大，需要拆分成网关/策略/执行/风控多个服务并独立扩展。
承接页：把对冲系统做成“可上线”的交易工程
如果你正在从零搭建或重构跨交易所执行系统，建议先把工程底座打牢：统一适配层（行情/订单范式）→ 执行网关（并发下单 + 限频 + 生命周期）→ 风控/仓位中台（预算与敞口治理）→ 可观测性（延迟/烂尾单/补偿链路）。可参考：TechNova 交易系统整体解决方案。