低时延交易平台智能订单路由相关挑战及技术问题咨询

1. 多交易场所明暗订单簿兼容的低时延订单路由运作逻辑 #

整个链路完全围绕「减少不必要的内存拷贝和计算开销」设计，核心步骤如下：

• 预配置阶段：所有对接的交易场所规则（手续费、最小报单量、报单限制）、暗池准入要求、流动性阈值等参数提前写入本地内存数据库，运行过程中无磁盘IO操作。
• 实时行情聚合：行情接收模块通过DPDK/RDMA内核旁路技术直接从网卡取数，将公开交易所的可见订单簿topN档（通常为top5/top10，过多档位会徒增计算开销）、暗池对外披露的可成交上下限额度、最近成交价格做实时对齐，所有聚合数据存在共享内存空间，路由模块可直接读取，无需跨进程通信。
• 订单拆分与优先级判定：收到用户报单后，首先根据报单类型（市价/限价）、总成交量做初步计算：如果单一市场可完全成交则直接发单；否则优先扫所有可见订单簿的对手方最优档位，剩余未成交量再匹配暗池的可成交额度，暗池成交优先级高于公开市场的次优档位，避免大额报单滑点。
• 报单分发与回报合并：拆分后的子单按照成交优先级排序，走专门的低时延链路直接发往对应交易场所，成交回报实时汇总，未成交余单会自动触发新一轮路由匹配，直至订单全部完成或撤单。

2. 低时延智能订单路由（SOR）的核心实现挑战 #

• 多源行情时钟同步误差：不同交易场所的行情时间戳采用各自的时钟源，跨场所的同步精度需要控制在1微秒以内才不会出现订单簿聚合失真，跨地域对接交易所时这个要求几乎到了硬件能力的极限，一旦同步出错就会导致路由策略判断错误，出现滑点甚至拒单。
• 暗池信息不透明：暗池不会披露全量订单簿，仅能拿到预估的可成交额度，经常出现发单后实际可成交量远低于预期的情况；同时部分暗池存在信息泄露风险，大额报单进入暗池后可能被高频做市商捕捉到信号，拉抬公开市场价格反而造成更大滑点。
• 多市场规则兼容成本：不同交易场所的最小报价单位、撤单惩罚规则、报单频率限制差异极大，SOR需要实时计算撤单、重发的隐形成本，这些额外计算很容易拉高链路时延，平衡精度和性能的难度极高。
• 极端行情下的性能稳定性：行情剧烈波动时，订单簿更新频率会从每秒数千次暴涨至十几万次，一旦路由模块的计算能力跟不上出现队列堆积，报单延迟几微秒就会完全抢不到最优档位，策略直接失效。

3. 超低时延下的行情研判与AI算法应用问题 #

首先针对第一个子问题：不需要在数十微秒的tick to trade周期内完成全量行情研判。tick to trade是指行情报文到达网卡到报单报文发出的主链路耗时，主链路仅执行最核心的最优价匹配、流动性校验等确定性规则逻辑，更复杂的行情趋势判断、路由策略参数优化全部放在异步旁路模块执行，通常每秒更新一次策略参数即可，不会占用主链路的时间预算。

针对第二个子问题：超低时延要求确实会大幅限制AI/机器学习算法的在线应用，但并非完全不能用。当前哪怕是极轻量化的小模型，一次推理也需要几微秒到几十微秒的耗时，直接放在主交易链路会直接占满整个tick to trade的时间预算，根本达不到低时延要求。目前行业通用的做法是把AI/ML的计算全部移到离线和旁路半实时环节：比如离线用历史行情数据训练暗池成交概率、滑点预测模型，训练完成后将模型输出的权重参数（比如不同行情下各个交易场所、暗池的成交优先级）更新到主链路的内存查询表中，主链路仅做查表操作，不需要实时推理。而在线实时学习几乎不会被采用，一方面在线梯度更新的开销太大，会额外增加时延；另一方面模型在线更新的稳定性不可控，很容易引发交易事故。

内容的提问来源于stack exchange，提问作者Jimboi