第四章：做市商技术架构

低延迟系统、订单管理系统、风控引擎、行情数据管道

做市商的技术架构，说白了就是一台高速运转的印钞机——前提是你得把每个零件都打磨到极致。我做了这么多年，见过太多团队在策略上花了大功夫，结果系统延迟高了几个毫秒，利润全被吃掉了。今天咱们就聊聊这四大核心模块。

核心观点：做市商的技术架构不是简单的“买软件、搭服务器”，而是一个需要深度定制的系统工程。低延迟是生命线，订单管理是骨架，风控是刹车，行情管道是眼睛——缺一不可。

4.1 低延迟系统：每一微秒都是钱

先说说低延迟。你可能觉得“快一点慢一点无所谓”，但在我参与的一个项目中，系统延迟从500微秒降到100微秒，年化收益直接提升了15%。为什么会这样？因为做市商赚的就是买卖价差，你比别人慢一拍，订单就被抢走了。

低延迟系统的核心在于三个层面：

  • 硬件层面：用FPGA代替CPU处理行情和订单。我建议你直接上Xilinx的板子，虽然贵，但延迟能压到纳秒级。
  • 网络层面：尽量把服务器放在交易所的同一机房，或者用专线直连。我曾经见过一个团队，为了省几万块月租，结果延迟多了2毫秒，最后亏了上百万。
  • 软件层面：用C++或Rust写核心逻辑，避免GC（垃圾回收）带来的抖动。嗯，这里要注意——别用Java做高频部分，除非你想体验“随机暂停”的刺激。

个人经验：我在搭建低延迟系统时，习惯用DPDK（数据平面开发套件）来绕过内核协议栈。说白了，就是让网卡直接把数据扔给用户态程序，省掉内核的上下文切换。效果立竿见影，延迟能降30%以上。

4.2 订单管理系统：别让订单“飞”了

订单管理系统（OMS）是连接策略和交易所的桥梁。你想想看，如果OMS出了问题，订单发不出去或者重复发送，那后果不堪设想。我遇到过最惨的一次，是OMS的队列满了，导致一笔大单延迟了3秒才发出，结果市场已经变了方向，直接亏了50万。

一个好的OMS应该具备以下能力：

  1. 订单生命周期管理：从创建、提交、确认到成交、撤销，每一步都要有状态机跟踪。
  2. 订单路由：支持多交易所、多账户的智能路由。比如，当币安延迟高时，自动切换到OKX。
  3. 订单簿同步：实时维护本地订单簿，避免因网络延迟导致“看到的价格和实际价格不一致”。
  4. 错误处理：网络断开、交易所拒绝、资金不足……这些异常情况都要有预案。

这里我贴一段伪代码，展示OMS的核心逻辑：

class OrderManager {
    // 订单状态机
    enum State { PENDING, SUBMITTED, PARTIAL_FILLED, FILLED, CANCELLED, REJECTED }
    
    // 提交订单
    function submitOrder(order) {
        if (riskEngine.check(order) == false) {
            return "风控拒绝";
        }
        // 发送到交易所
        exchange.send(order);
        // 更新状态
        order.state = SUBMITTED;
        // 启动超时监控
        timer.start(order.id, 500ms);
    }
    
    // 处理成交回报
    function onFill(fill) {
        order.filledQty += fill.qty;
        if (order.filledQty == order.qty) {
            order.state = FILLED;
        } else {
            order.state = PARTIAL_FILLED;
        }
        // 通知策略
        strategy.onOrderUpdate(order);
    }
}

避坑指南：我曾经犯过一个错误——没有给订单设置超时机制。结果有一次交易所网络卡顿，订单卡在“已提交”状态，我以为没成交就重新发了一笔，结果两笔都成交了，仓位直接翻倍。所以，一定要给每个订单加超时检查和自动撤销逻辑。

4.3 风控引擎：别让黑天鹅把你打趴下

风控引擎是系统的刹车。没有它，你的策略再牛也白搭。我见过太多做市商，平时赚得盆满钵满，结果一次极端行情就爆仓了。说白了，风控不是限制你赚钱，而是让你活得久。

风控引擎通常包含以下几个模块：

风控类型 检查内容 触发动作
资金风控 账户余额、可用保证金 拒绝开仓、强制平仓
仓位风控 单品种持仓上限、总敞口 限制下单、自动减仓
订单风控 单笔金额、频率、价格偏离 拒绝订单、暂停交易
市场风控 波动率、流动性、涨跌幅 降低杠杆、暂停策略

我个人习惯把风控引擎设计成“可插拔”的。什么意思呢？就是每个风控规则都是一个独立的模块，可以动态加载和卸载。比如，平时只开资金风控和仓位风控，但遇到重大新闻时，手动开启市场风控，把波动率阈值调低。

个人经验：我建议你在风控引擎里加一个“熔断机制”。当连续亏损达到一定金额时，自动暂停所有交易。我曾经在一个项目中，因为没加熔断，结果策略在震荡行情里来回止损，一天亏了20%。加了熔断后，至少能保住本金。

4.4 行情数据管道：喂饱你的策略

行情数据管道是策略的“眼睛”。没有实时、准确的行情，你的策略就是瞎子。你想想看，如果行情延迟了1秒，你的报价可能已经过时了，做市商就成了“接盘侠”。

行情数据管道的设计要点：

  • 多源聚合：同时接入多个交易所的行情，做去重和排序。我建议用WebSocket + TCP双通道，WebSocket用于实时推送，TCP用于补数据。
  • 数据清洗：过滤掉异常数据（比如价格跳变、时间戳错乱）。我曾经遇到过交易所推送的行情里，居然有负价格——嗯，这种数据必须扔掉。
  • 本地快照：维护一个内存中的订单簿快照，用于策略快速查询。注意，快照的更新频率要足够高，最好每笔成交都更新。
  • 历史存储：把行情数据存到时序数据库（比如InfluxDB）里，用于回测和分析。

下面我用一张SVG图来展示行情数据管道的整体流程：

行情数据管道架构图 交易所A 交易所B 交易所C 数据聚合层 去重 排序 清洗 时间对齐 本地订单簿 内存快照 时序数据库 历史回放 策略 模块

从这张图可以看出，行情数据从交易所出发，经过聚合、清洗，最终形成本地快照和历史数据，供策略模块消费。我建议你把数据管道的延迟控制在1毫秒以内——超过这个值，策略的报价就会明显滞后。

避坑指南：我曾经在行情管道里犯过一个低级错误——没有做数据去重。结果同一个成交数据被推送了两次，策略以为发生了两笔交易，导致订单簿快照错乱。所以，一定要在聚合层加一个基于交易ID的去重逻辑。

小结

做市商的技术架构，说白了就是四个字：快、准、稳、全。低延迟系统让你快，订单管理系统让你准，风控引擎让你稳，行情数据管道让你全。这四个模块环环相扣，任何一个短板都会成为你的致命伤。

我个人建议，在搭建系统时，先从行情管道和风控引擎入手——因为数据是基础，风控是底线。等这两个模块稳定了，再优化低延迟和订单管理。别一上来就追求极致速度，结果风控没做好，一次黑天鹅就让你回到解放前。

专注资料整理

← 上一章 📖 返回目录 下一章 →