4. 通信机制详解
在自动驾驶系统中，通信机制是连接感知、定位、预测、规划、控制等模块的“神经系统”。Apollo Cyber RT 作为面向自动驾驶场景的实时中间件，围绕高吞吐、低延迟、确定性调度设计了一整套通信能力。理解发布/订阅、请求/响应、共享内存、零拷贝、序列化与反序列化以及 QoS 策略，是进行性能调优与可靠性保障的前提。
一、核心通信模型：发布/订阅与请求/响应
Cyber RT 最常用的通信模式是发布/订阅（Pub/Sub）。发布者将消息写入某个 Channel，订阅者按需订阅该 Channel，二者通过节点（Node）与 Reader/Writer 解耦。该模型适合传感器数据流、感知结果、规划轨迹等“一对多、持续流式”的场景。
请求/响应（Service/Client）则用于“一问一答”的同步或异步调用，例如查询地图、请求标定参数、触发诊断。它强调调用语义与结果返回，适合低频、需要明确响应的交互。
二、共享内存与零拷贝：降低大消息传输成本
自动驾驶中的点云、图像、高精地图等消息体积巨大，若每次通信都经历“序列化→内核拷贝→反序列化”，CPU 与内存带宽会被迅速耗尽。Cyber RT 通过共享内存（Shared Memory）与零拷贝（Zero Copy）机制，让发布者与订阅者直接访问同一块内存区域，避免重复拷贝。
典型数据通路如下：
发布者构造消息 → 序列化到共享内存块 → 写入 Channel 索引
订阅者读取索引 → 直接映射同一内存块 → 反序列化或原地解析
零拷贝并非“完全不拷贝”，而是减少用户态与内核态之间的数据搬运。对于跨主机通信，仍需走网络协议栈；对于同机进程，共享内存可显著降低延迟。实践中需注意：共享内存块的生命周期管理、读写同步、以及消息被覆盖时的引用计数问题。
三、序列化与反序列化：协议选择与性能权衡
Cyber RT 默认使用 Protobuf 作为消息描述与序列化格式。Protobuf 具备跨语言、向后兼容、体积紧凑等优势，适合定义稳定的消息接口。但在高频、低延迟场景中，序列化与反序列化的 CPU 开销不可忽视。
| 机制 | 适用场景 | 性能特征 | 注意事项 |
|---|---|---|---|
| 发布/订阅 | 传感器流、感知结果、规划轨迹 | 高吞吐、一对多、异步 | 需关注队列深度与丢帧策略 |
| 请求/响应 | 地图查询、参数标定、诊断触发 | 低频、有明确返回 | 需设置超时与重试上限 |
| 共享内存 | 同机大消息传输 | 低延迟、高带宽 | 生命周期与同步管理复杂 |
| 零拷贝 | 点云、图像、大数组 | 减少拷贝与内存占用 | 跨主机时退化为网络传输 |
| Protobuf 序列化 | 接口定义与持久化 | 体积小、兼容性好 | 高频场景需评估 CPU 开销 |
四、QoS 策略与通信可靠性保障
QoS（Quality of Service）策略决定消息在“不可靠网络、节点抖动、消费不及时”等情况下的行为。Cyber RT 的 QoS 通常围绕以下维度配置：
- 可靠性：Reliable 保证消息不丢，Best Effort 允许丢包以换取低延迟。
- 历史深度：Keep Last 只保留最近 N 条，Keep All 保留全部（需配合资源限制）。
- 队列深度：控制发送/接收缓冲区大小，过小易丢帧，过大增加延迟。
- 截止时间：为消息设定最大等待时间，超时触发降级或告警。
- 生命周期：控制消息在队列中的存活时间，避免过期数据被消费。
五、案例：感知到规划的通信链路调优
某自动驾驶项目在感知模块输出障碍物列表到规划模块时，出现规划周期抖动。排查发现：感知消息体积较大，且 QoS 使用默认队列深度，导致消息在 Channel 中排队。优化措施包括：
- 将感知到规划的 Channel 切换为共享内存传输，减少序列化与拷贝开销。
- 将 QoS 历史深度设为 Keep Last 1，确保规划始终消费最新障碍物信息。
- 对控制指令链路启用 Reliable + 小队列，保证关键指令不丢失。
- 通过 Cyber RT 的监控工具观察 Channel 延迟与丢帧计数，验证优化效果。
# 查看 Channel 通信状态（示意）
cyber_monitor
# 关注字段：消息频率、延迟、丢帧数、队列占用
复盘结论：通信机制的选择不是“越高级越好”，而是要与数据特征、实时性要求和可靠性目标匹配。大消息走共享内存与零拷贝，小消息走轻量传输；关键指令用 Reliable，流式数据可接受 Best Effort；QoS 参数必须结合端到端延迟预算进行设定。