做市商基础设施：交易系统架构与性能优化
做市商这行，说白了就是跟时间赛跑。你系统慢一毫秒，别人就把你的单子吃了。我刚开始带团队搭建系统时，踩过不少坑，今天把这些经验掰开揉碎讲给你听。
一、核心系统架构：OMS、EMS、RMS
做市商的交易系统，通常拆成三个核心模块。我个人习惯把它们比作「大脑、手脚、风控官」。
- OMS（订单管理系统）：订单的「大脑」。负责接收策略信号，生成订单，管理订单生命周期。说白了，就是决定「什么时候、以什么价格、买多少」。
- EMS（执行管理系统）：订单的「手脚」。负责把OMS的指令发到交易所，处理撤单、改单，管理订单路由。它要处理的是「怎么最快、最稳地把单子塞进去」。
- RMS（风险管理系统）：订单的「风控官」。实时监控敞口、保证金、交易限额。一旦越界，直接砍单或报警。
这三个模块必须解耦，但又得高效协作。我在项目中遇到过一个问题：RMS和OMS耦合太紧，导致风控检查拖慢了订单下发速度。后来我们改成异步消息队列，RMS只做检查，不阻塞订单流，延迟直接降了40%。
关键设计原则：OMS只管生成订单，EMS只管执行，RMS只管风控。谁也别越界。
二、数据源与市场连接
做市商离不开数据。你想想看，没有实时行情，你怎么定价？没有历史数据，你怎么回测？
主流数据源就这几个：
| 数据源 | 用途 | 延迟 | 成本 |
|---|---|---|---|
| 彭博（Bloomberg） | 定价曲线、参考数据、新闻 | 中等（毫秒级） | 高 |
| 路透（Refinitiv） | 实时行情、历史数据 | 低（微秒级） | 中高 |
| 交易所API（CME、Eurex等） | 订单簿、成交数据 | 极低（纳秒级） | 按流量计费 |
嗯，这里要注意：彭博和路透的数据虽然全，但延迟高，不适合做高频做市。真正用来做市的数据，必须直接从交易所API拿。我曾经有个同事，用彭博数据做定价，结果行情延迟了50毫秒，被对手盘反复收割。后来我们全部切到交易所直连，才稳住。
我的建议：行情数据走交易所直连，参考数据（如曲线、信用利差）走彭博/路透。别混用。
三、延迟与性能优化基础
做市商拼的就是延迟。你比别人慢1微秒，可能就抢不到最优价。我见过最极端的案例：某家做市商为了省5微秒，把服务器搬到了交易所机房隔壁，光纤长度缩短了10米。
优化延迟，通常从这几个方向入手：
- 硬件层面：用FPGA处理行情，用Solarflare网卡，用低延迟交换机。说白了，就是砸钱买时间。
- 软件层面：用C++或Rust写核心逻辑，避免GC（垃圾回收）。我习惯用C++写订单处理模块，Python写策略原型。
- 网络层面：用UDP代替TCP，减少握手开销。用多播接收行情，减少单播的带宽压力。
- 数据层面：用内存数据库（如Redis）存实时数据，避免磁盘I/O。用共享内存做进程间通信，比Socket快一个数量级。
避坑指南：我曾经为了追求极致性能，把所有逻辑都塞进一个进程。结果一个bug导致整个系统崩溃，订单全丢了。后来我学乖了：关键模块必须隔离，哪怕多花几微秒。
为什么会这样？因为做市商系统最怕的不是慢，而是不稳定。你慢一点，最多少赚点；你崩了，可能直接亏穿。
四、知识体系总览
下面这张图，是我自己总结的做市商基础设施架构。你可以把它当成一个检查清单，看看自己的系统缺了哪块。
这张图里，每一层都依赖下一层。策略层依赖OMS/EMS/RMS，而它们又依赖数据层和基础设施层。性能优化是贯穿始终的，不是最后才做。
一句话总结：做市商系统，架构决定上限，性能决定下限。架构乱了，性能再好也白搭；性能差了，架构再漂亮也赚不到钱。
好了，这一章就讲到这里。下一章我们会深入OMS的订单生命周期管理，聊聊订单状态机、撤单逻辑、以及如何避免「幽灵订单」。