一、消息延迟概述

做感知联调这些年，我踩过最多的坑，就是消息延迟。说白了，消息延迟就是数据从发送到接收之间，多出来的那段时间。你想想看，传感器采集到数据，经过网络、经过处理、再到决策模块，这中间每一步都可能产生延迟。

我记得刚入行那会儿，总觉得延迟不就是慢几毫秒吗？直到有一次，自动驾驶项目在测试时，前方突然出现障碍物，系统却晚了200ms才做出反应。嗯，那次差点出事。从那以后，我对消息延迟就格外敏感了。

什么是消息延迟

消息延迟，指的是消息从发送端发出，到接收端成功处理之间的时间差。这个时间差，我习惯把它拆成三部分：

• 传输延迟：数据在物理链路上传输的时间。光纤、网线、无线，介质不同，延迟也不同。
• 处理延迟：CPU处理数据、协议栈解析、序列化/反序列化这些操作消耗的时间。
• 排队延迟：数据在缓冲区里排队等待处理的时间。这个最容易被忽略，但往往是最坑的。

我在项目中遇到过一种情况：网络带宽明明够用，但延迟就是降不下来。查了半天，发现是消息队列的缓冲区设得太大了，数据全堵在那里排队。你说气不气人？

延迟的常见表现

延迟不是只有一种样子。根据我的经验，常见的延迟表现有这几种：

类型	表现	典型场景
固定延迟	每次延迟时间基本一致	网络传输、固定处理流程
抖动延迟	延迟时间忽大忽小	CPU负载波动、网络拥塞
突发延迟	平时正常，偶尔暴增	垃圾回收、中断处理
累积延迟	延迟随时间逐渐增大	缓冲区溢出、内存泄漏

我曾经遇到过一个特别典型的抖动延迟问题。一个激光雷达的数据，有时候3ms就到了，有时候要等50ms。查到最后，发现是系统里有个定时器任务，每隔100ms会抢占CPU资源。嗯，这就是典型的「隐形杀手」。

延迟对感知系统的影响

感知系统对延迟有多敏感？我给你说几个真实案例：

• 目标检测：摄像头采集到图像，如果延迟超过100ms，车辆可能已经移动了好几米。检测到的目标位置，其实是「过去的位置」。
• 传感器融合：激光雷达和摄像头的数据如果时间戳对不上，融合出来的结果就是错的。我见过一个项目，就是因为延迟不一致，导致融合后的目标位置偏差了半米。
• 决策规划：决策模块拿到的是延迟后的数据，做出的规划自然也是滞后的。这在高速场景下尤其危险。

为什么会这样？因为感知系统本质上是一个实时系统。实时系统的核心要求，就是在规定时间内完成规定动作。延迟一旦超标，整个系统的可靠性就崩塌了。

你想想看，一个自动驾驶系统，如果感知延迟从50ms涨到200ms，那车辆的反应距离就会从1.5米变成6米（按30m/s计算）。这4.5米的差距，可能就是安全与事故的分界线。

所以，在感知联调中，我始终把延迟监控放在第一位。每次调试，我都会先确认：消息从采集到消费，到底花了多少时间？每个环节的延迟是否在预期范围内？

说白了，延迟就是感知系统的「血压」。血压高了，系统就危险了。而我们要做的，就是时刻监测这个「血压」，一旦发现异常，立刻排查原因。