2. 交易链路基础
在讨论实盘延迟、拒单率与成交率之前，必须先建立一条完整的“交易链路”认知。很多监控指标之所以失真，并不是采集工具不好，而是没有把指标挂到正确的链路段上。一笔订单从想法到成交，中间要穿过行情、策略、风控、路由、网关、交易所撮合等多个环节，每个环节都有自己的耗时、失败模式和可观测信号。只有先拆清楚链路，后面的延迟分解、拒单归因和成交率优化才有落脚点。
一、核心原理：交易链路是一条“多段串联+局部并行”的处理管道
从系统视角看，交易链路可以抽象为一条数据流：行情数据进入系统 → 策略基于行情计算信号 → 风控对信号生成的订单做检查 → 订单被路由到目标交易所 → 交易所撮合并回报结果。这条链路不是单一进程，而是由多个服务、队列、网络连接和外部系统串联而成。串联意味着总延迟近似等于各段延迟之和，任何一段抖动都会传导到最终成交结果。
同时，链路内部存在并行：行情接入可能同时维护多个交易所的行情源；策略计算可能并行评估多个标的；订单路由可能同时向多个目的地发单。因此，监控不能只看“总耗时”，而要能按段、按交易所、按策略实例拆开。核心原理可以概括为三点：
- 分段可观测：每个环节都要有进入时间、离开时间和结果状态，否则无法定位瓶颈。
- 状态可追踪：订单从创建、风控通过、路由发出、网关确认、交易所接受、部分成交到完全成交，状态必须可关联。
- 失败可归因：拒单可能来自风控、路由、网关、交易所限流或参数错误，必须区分来源。
关键认知：延迟不是单一数字，而是“链路各段耗时 + 排队等待 + 网络往返 + 交易所处理”的组合。成交率也不是单一比率，而是“发单成功率 × 交易所接受率 × 撮合概率”的乘积。
二、方法流程：五段链路拆解与监控埋点
下面按五个核心环节拆解，并给出每段应采集的关键信号。
- 行情接入：通过交易所 WebSocket 或专线接收行情，完成解析、归一化和本地订单簿维护。关键信号包括行情到达时间戳、解析耗时、订单簿更新延迟、行情源心跳状态。
- 策略计算：策略读取行情快照，计算因子、信号和下单意图。关键信号包括策略触发时间、计算耗时、信号生成时间、目标仓位与当前仓位差异。
- 风控检查：对订单做资金、持仓、价格偏离、频率、单笔上限等检查。关键信号包括风控进入时间、检查项、通过/拒绝原因、拒绝码。
- 订单路由：根据交易所、账户、标的和路由规则选择通道，生成订单并发送到网关。关键信号包括路由决策耗时、目标通道、订单 ID、发送时间。
- 交易所撮合：订单到达交易所后进入撮合队列，产生接受、拒绝、部分成交、完全成交或撤单回报。关键信号包括交易所确认时间、成交回报时间、成交价格与数量、拒单错误码。
为了把上述环节串起来，建议在订单对象上携带统一的 trace_id，并在每个环节写入结构化日志。例如：
{
"trace_id": "ord-20240612-000871",
"symbol": "BTCUSDT",
"stage": "risk_check",
"enter_ts": 1718179200123,
"leave_ts": 1718179200128,
"result": "pass",
"reason": null
}当日志按 trace_id 聚合后，就能还原一笔订单的完整路径，并计算各段耗时。下面这张表给出了链路分段与监控指标的对应关系，可作为埋点清单使用。
| 链路段 | 核心动作 | 关键监控指标 | 典型失败模式 |
|---|---|---|---|
| 行情接入 | 接收、解析、更新订单簿 | 行情延迟、解析耗时、心跳丢失次数 | 断线重连、行情源延迟、订单簿错乱 |
| 策略计算 | 因子计算、信号生成 | 计算耗时、信号频率、信号偏差 | 计算超时、信号抖动、重复触发 |
| 风控检查 | 资金、持仓、频率、价格检查 | 风控耗时、拒绝率、拒绝原因分布 | 误拒、漏拒、规则冲突 |
| 订单路由 | 选通道、生成订单、发送网关 | 路由耗时、发送成功率、通道分布 | 通道不可用、路由错误、重复发单 |
| 交易所撮合 | 接受、撮合、回报成交 | 确认延迟、成交率、拒单率、滑点 | 限流、拒单、部分成交、回报丢失 |
三、案例场景：一笔限价单的链路还原
假设策略在 BTCUSDT 上生成一笔买入限价单，价格 68000，数量 0.5。链路可能如下：行情在 T0 到达，策略在 T0+2ms 完成计算并生成订单；风控在 T0+3ms 进入，检查资金和频率后通过；路由在 T0+5ms 选择交易所 A 的通道并发送；网关在 T0+8ms 发出；交易所于 T0+35ms 确认接受；最终在 T0+120ms 完全成交。此时总延迟约 120ms，其中交易所撮合段占 85ms，是主要瓶颈。
如果这笔订单被拒绝，拒绝码可能来自不同层：风控返回 RISK_LIMIT_EXCEEDED，路由返回 NO_AVAILABLE_CHANNEL，网关返回 RATE_LIMIT，交易所返回 INSUFFICIENT_BALANCE 或 PRICE_OUT_OF_RANGE。只有把拒绝码与链路段绑定，拒单率分析才不会变成“一锅粥”。
实操建议：在监控面板上同时展示“按链路段分组的 P50/P95/P99 延迟”和“按拒绝码分组的拒单率”。前者定位慢，后者定位错，两者结合才能指导优化。
四、误区与复盘：链路拆解中最容易犯的错
误区一：只看总延迟，不看分段。总延迟升高时，无法判断是行情慢、策略慢还是交易所慢，优化方向容易跑偏。
误区二：把拒单率当成单一指标。拒单可能来自风控、路由、网关或交易所，混在一起会掩盖真实问题。例如风控误拒升高，但交易所拒单下降，总拒单率可能看起来平稳。
误区三：忽略时间戳来源不一致。不同机器、不同进程的时间戳如果没有统一时钟同步，分段耗时会出现负值或虚假放大。建议使用 NTP 或 PTP 同步，并在日志中记录时钟偏差。
误区四：没有统一订单标识。如果订单在网关和交易所侧使用不同 ID，就无法把发单、确认和成交回报关联起来，成交率统计会丢失大量样本。
复盘要点：每次延迟异常或拒单率飙升，都应先按链路分段定位，再检查该段的日志、指标和外部状态。不要直接跳到“网络问题”或“交易所问题”的结论。
把交易链路拆成行情接入、策略计算、风控检查、订单路由和交易所撮合五段，并为每段建立时间戳、状态和拒绝码，是后续所有监控工作的基础。只有链路清晰，延迟才能被分解，拒单才能被归因，成交率才能被真正提升。