3. 延迟的定义与分类

在实盘交易系统中，“延迟”几乎是最常被提及、也最容易被混用的概念。有人把行情推送慢叫延迟，有人把订单回报慢叫延迟，还有人把策略计算耗时也叫延迟。若不在同一套定义下讨论，监控指标就会失真，排障方向也会跑偏。本节把实盘链路中的延迟拆成五类：网络延迟、系统延迟、处理延迟、排队延迟与端到端延迟，并给出可落地的区分方法与监控口径。

一、核心原理：延迟是时间戳之差，不是感觉

延迟的严格定义是：在一条确定的信号路径上，两个事件发生时刻的时间差。要测量它，必须满足三个条件：事件可观测、时间戳可对齐、路径可界定。实盘中常见的错误是拿不同机器、不同时钟源的时间戳直接相减，结果把时钟偏差当成了延迟。

五类延迟的边界如下：

• 网络延迟：数据包在网卡、交换机、路由器、跨机房链路上传输所消耗的时间，通常用 RTT 或单向时延衡量。
• 系统延迟：操作系统内核协议栈、中断处理、上下文切换、内存拷贝、锁竞争等带来的时间，属于“机器内部但非业务逻辑”的部分。
• 处理延迟：策略引擎、风控、订单生成等业务代码真正执行的时间，是开发者最可控的一段。
• 排队延迟：消息在队列、线程池、撮合前置缓冲、网关限流队列中等待被处理的时间。
• 端到端延迟：从行情源产生 tick，到订单被交易所确认（或策略信号生效）的总时间。

它们的关系可以概括为：端到端延迟 ≈ 网络延迟 + 系统延迟 + 处理延迟 + 排队延迟 + 交易所侧不可控延迟。注意“≈”而非“=”，因为部分环节会并行或重叠。

二、方法流程：如何逐段测量与归因

要把五类延迟区分开，推荐按“打点—对齐—归因”三步走。打点要求在每个关键边界记录单调时钟时间戳；对齐要求所有节点使用同一时钟源（如 PTP/NTP）并记录偏差；归因则把端到端差值拆到各段。

1. 在行情接入处记录 t0_tick_in，在策略输出处记录 t1_signal_out。
2. 在订单网关入口记录 t2_order_in，在发往交易所前记录 t3_order_send。
3. 收到交易所确认时记录 t4_ack。
4. 计算：网络段 ≈ t0 前后链路 RTT；系统段 ≈ 内核收发耗时；处理段 = t1 - t0 中的业务计算；排队段 = t2 - t1 或 t3 - t2 中的等待；端到端 = t4 - t0。

# 示例：从日志中提取各段延迟（单位 ms）
tick_in=1690000000123
signal_out=1690000000131   # 处理延迟 8ms
order_in=1690000000136     # 排队延迟 5ms
order_send=1690000000139   # 系统延迟 3ms
ack=1690000000158          # 网络+交易所 19ms
端到端 = 158 - 123 = 35ms

三、案例/场景：一次“延迟突增”的复盘

某策略在开盘后 5 分钟端到端延迟从 30ms 升至 220ms。初步怀疑网络，但 RTT 监控正常。逐段拆解后发现：网络延迟稳定在 12ms，系统延迟 4ms，处理延迟 9ms，而排队延迟从 3ms 飙升至 180ms。根因是风控线程池队列积压，行情突发时任务提交速度超过消费速度。

这个案例说明：端到端指标只能告诉你“变慢了”，不能告诉你“哪里慢”。若没有分段打点，团队很可能去扩容带宽，而真正要改的是队列容量、消费者并发或背压策略。

四、误区与复盘：别把五类延迟混为一谈

复盘时应固定三个动作：第一，确认时间戳来源与时钟同步状态；第二，按五类延迟分别出分位报表；第三，对异常段做单变量验证，例如只压测队列、只压测网络。只有把定义、测量、归因三者对齐，后续的拒单率与成交率监控才有可靠的时间基准。

最后强调一个工程习惯：在系统设计阶段就为每类延迟预留“预算”，例如网络 15ms、系统 5ms、处理 10ms、排队 5ms，端到端目标 50ms 以内。预算一旦明确，监控阈值、告警策略和容量规划都会变得清晰可执行。