第十一章：做市策略实盘部署
交易系统架构、低延迟通信、风控模块集成、监控与告警系统——这四个词，说白了就是你的策略能不能在真实战场上活下来。我见过太多漂亮的回测曲线，一上实盘就崩了。为什么？因为部署环节的坑，回测里根本看不到。
一、交易系统架构：别让架构拖累你的策略
做市策略对系统架构的要求，跟普通CTA完全不一样。普通策略可能一秒发一次单，做市策略一秒钟可能要发几十次甚至上百次。你想想看，如果架构设计不合理，光是网络开销就能吃掉你一半的利润。
我个人习惯把系统拆成三层：
- 接入层：负责跟交易所打交道，处理行情和订单
- 策略层：做市逻辑、定价模型、风险管理
- 执行层：订单管理、路由、成交反馈
为什么要拆？因为每一层的优化方向不一样。接入层要快，策略层要稳，执行层要准。混在一起，你改一个地方可能影响全局。
核心原则：接入层和策略层之间用内存队列通信，不要走网络。我在项目中遇到过，有人把行情数据通过Redis推给策略层，结果延迟多了几百微秒，做市策略直接亏钱。
这里我画了一张架构图，你看一眼就明白了：
二、低延迟通信：微秒级的生死时速
做市策略的延迟，直接决定你的成交率。你报的买价比别人慢1毫秒，可能就吃不到单了。这不是夸张，这是现实。
我总结了几条低延迟通信的实战经验：
- 用UDP不要用TCP——TCP的重传机制在低延迟场景下是灾难。行情数据丢几个包无所谓，但延迟高了就完了。
- 共享内存——进程间通信用共享内存，不走socket。我在项目中把行情从接入层到策略层的延迟从50微秒降到了2微秒。
- CPU亲和性绑定——把关键线程绑定到特定CPU核心，避免上下文切换。嗯，这里要注意，别把两个高负载线程绑到同一个核心上。
- 内核旁路——用DPDK或者Solarflare的OpenOnload，跳过内核协议栈。这个优化能再省10-20微秒。
小技巧：我曾经把行情处理线程和策略计算线程绑到同一个CPU的不同核心上，然后用共享内存通信。结果延迟从30微秒降到了5微秒。说白了，就是让数据尽量少搬家。
三、风控模块集成：别让一次事故毁掉所有利润
做市策略的风控，跟普通策略不一样。普通策略可能设个止损就完了，做市策略要管的东西多得多。
我建议风控模块至少包含以下几层：
| 风控层级 | 检查内容 | 触发动作 |
|---|---|---|
| 事前风控 | 订单价格是否合理、数量是否超限 | 拒绝下单 |
| 事中风控 | 持仓敞口、希腊字母暴露、资金使用率 | 自动撤单、对冲 |
| 事后风控 | 日盈亏、最大回撤、成交率异常 | 暂停策略、报警 |
你想想看，如果风控模块跟策略模块跑在同一个进程里，风控挂了策略也挂了。所以风控必须独立部署，独立进程，甚至独立机器。
避坑指南：我曾经把风控阈值设得太紧，结果市场波动稍微大一点，风控就把所有订单撤了，做市策略直接空仓。后来我加了动态阈值，根据市场波动率自动调整风控参数。
四、监控与告警系统：你的第二双眼睛
做市策略是24小时运行的，你不可能一直盯着屏幕。监控系统就是你的替身。
我个人习惯把监控分成三个维度：
- 系统监控：CPU、内存、网络延迟、磁盘IO。这些指标异常，往往预示着更大的问题。
- 策略监控：订单成交率、买卖价差、库存水平、PnL曲线。这些直接反映策略的健康状况。
- 市场监控：波动率、流动性、价差变化。市场环境变了，策略可能也需要调整。
告警系统要分级别：
- 信息级：策略启动、停止、参数变更。发个邮件就行。
- 警告级：持仓超限、成交率下降、延迟升高。发短信或者钉钉消息。
- 紧急级：风控触发、策略异常退出、网络断开。直接打电话，别犹豫。
我的经验：告警阈值别设得太敏感。我曾经把延迟告警设成50微秒，结果一天收到几百条告警，最后直接无视了。后来改成连续5次超过100微秒才告警，效果好了很多。
监控面板我推荐用Grafana，数据源用InfluxDB或者Prometheus。展示几个关键指标：实时PnL、订单成交率、买卖价差、库存水平。别搞得太花哨，关键信息一目了然就行。
嗯，说到监控，还有一个容易被忽略的点——日志。日志要记录每一次下单、撤单、成交，以及风控触发的详细信息。出了问题，日志是你唯一的线索。我建议日志格式统一，包含时间戳、订单ID、价格、数量、原因等字段。
好了，实盘部署这块就讲这么多。记住一句话：架构决定上限，风控决定下限，监控决定你能不能睡个好觉。
无相订单流研究社 微信Lucian808555