3、TWAP交易系统架构：订单管理系统(OMS)、执行管理系统(EMS)、市场数据接口

好，咱们今天聊聊TWAP系统的骨架。说白了，一个能跑起来的TWAP执行系统，核心就三大块：订单管理系统（OMS）、执行管理系统（EMS），还有市场数据接口。这三者缺一不可，配合不好就容易出乱子。

我最早接触这套架构的时候，觉得不就是个下单工具嘛，有什么复杂的？后来真上了生产环境才发现，坑多着呢。你想想看，OMS管着订单的生命周期，EMS负责拆单和发单，数据接口负责喂行情——任何一个环节掉链子，交易员那边就得炸锅。

3.1 订单管理系统（OMS）——订单的“户籍警”

OMS，说白了就是管订单的“户口本”。从交易员创建一个大单开始，到它被拆成无数个小单，再到最终成交或撤销，OMS全程盯着。

OMS的核心职责：

• 订单创建与校验：交易员输入一个TWAP订单，OMS得先检查参数对不对。比如总数量不能为负，时间窗口不能太短，价格偏离不能太离谱。我见过一个新手把1000万股输成1000股，要不是OMS拦住了，那天的执行效果就全毁了。
• 订单状态管理：一个订单从“新建”到“执行中”，再到“完成”或“取消”，状态流转必须清晰。我个人习惯用状态机来管理，每个状态变更都记录时间戳，方便事后审计。
• 风险控制：这是我最看重的一点。OMS里通常会嵌入一些风控规则，比如单笔订单最大数量、日内累计成交量上限、自成交检查等等。我曾经遇到过一个bug，因为OMS没检查自成交，导致两个子单互相吃掉了对方的流动性，白白损失了手续费。

3.2 执行管理系统（EMS）——拆单与发单的“大脑”

EMS才是TWAP算法的核心执行者。它从OMS拿到一个大订单，然后按照时间均匀切分，生成一系列子单，再发到交易所。

EMS的工作流程：

1. 接收父订单：从OMS拿到订单ID、总数量、执行时长、开始时间等参数。
2. 计算切片：根据TWAP算法，把总数量按时间均匀分配。比如一个100万股的订单，执行4小时，那每小时就是25万股。但这里有个细节——实际切片时，我会把时间窗口再细分到分钟甚至秒级，比如每30秒发一个子单。
3. 生成子单：每个子单包含数量、价格（通常是市价或限价）、有效期等。我习惯用限价单，因为市价单在流动性差的时候容易滑点太大。
4. 发送与监控：子单发出去后，EMS要实时跟踪成交情况。如果某个子单没成交完，下一个子单要不要调整？嗯，这里就要引入“补偿机制”了——比如上一个子单只成交了80%，那下一个子单就多补20%。

3.3 市场数据接口——算法的“眼睛”

没有行情数据，TWAP就是瞎子在走路。市场数据接口负责把交易所的实时行情喂给EMS，让算法知道当前价格、成交量、买卖盘口等信息。

数据接口的关键要素：

• 行情类型：至少需要Level-1行情（最新价、成交量、买卖五档），如果做高频TWAP，最好用Level-2（逐笔成交、十档盘口）。
• 延迟要求：行情延迟必须可控。我遇到过用免费行情接口的情况，延迟动不动就几百毫秒，结果TWAP算法看到的“当前价格”其实是几百毫秒前的，发单时机全乱了。
• 数据清洗：行情数据偶尔会有异常值，比如价格突然跳到一个离谱的数字。EMS必须能识别并过滤掉这些“脏数据”，否则算法会做出错误决策。

3.4 三者如何协作？

我画了一张图，帮你理解这三者的关系：

从图上你能看到，OMS把父订单交给EMS，EMS根据市场数据接口提供的行情，拆成子单发到交易所。交易所返回成交回报后，EMS再更新订单状态，并反馈给OMS。这是一个闭环。

这里有个容易忽略的点：行情数据是单向流入EMS的，但EMS不能反过来影响行情。也就是说，EMS只能“看”行情，不能“改”行情。这个设计原则保证了系统的稳定性。

3.5 架构设计中的几个坑

最后，我分享几个实战中踩过的坑，希望能帮你少走弯路：

• OMS和EMS的通信延迟：如果OMS和EMS部署在不同的服务器上，网络延迟会导致订单状态更新不及时。我建议用内存队列或本地IPC通信，而不是走网络。
• 行情数据断流：市场数据接口一旦断流，EMS必须能自动切换到备用数据源，或者直接暂停发单。我曾经因为没做切换逻辑，导致算法在无行情的情况下连续发了10分钟的单，那叫一个惨。
• 子单数量过多：如果切片粒度太细，子单数量会暴增，给OMS和EMS都带来压力。我建议控制子单总数在几百到几千这个量级，别搞到几万甚至几十万。
• 补偿机制的边界：补偿逻辑不能无限放大。比如某个子单没成交，下一个子单最多补偿到原数量的1.5倍，否则容易造成单笔订单过大，引起市场冲击。