3. 消息调度基础

在 Apollo 这类自动驾驶与机器人系统中，消息调度层承担着“把数据从产生端可靠、及时地送到消费端”的核心职责。无论是激光雷达点云、摄像头图像、底盘状态，还是规划控制指令，都需要经过统一的消息中间件进行分发。理解消息队列、发布订阅模型、生产者消费者模式、同步与异步通信以及持久化与确认机制，是掌握 Apollo 通信工程的第一道门槛。

一、核心原理：从队列到发布订阅

消息队列是最基础的结构：生产者把消息放入队列尾部，消费者从队列头部取出，形成先进先出的缓冲。队列的价值在于解耦与削峰——当传感器瞬时产生大量数据时，队列可以暂存消息，避免消费者被压垮。但普通队列通常是“一条消息只被一个消费者取走”，适合任务分发场景。

发布订阅模型则更进一步：发布者（Publisher）把消息发送到某个“主题（Topic）”，所有订阅了该主题的订阅者（Subscriber）都会收到一份副本。它实现了一对多广播，是 Apollo 中感知、定位、规划等模块之间通信的主要方式。发布者不需要知道谁在订阅，订阅者也不需要知道消息来自哪里，双方只依赖主题名称和消息类型。

二、生产者消费者模式与同步异步通信

生产者消费者模式是消息队列的经典实现范式。生产者负责生成数据并写入缓冲区，消费者负责读取并处理，二者通过共享队列协作。该模式需要处理两个关键问题：缓冲区满时生产者如何等待，以及缓冲区空时消费者如何等待。常见策略包括阻塞等待、丢弃最旧消息、覆盖写入或动态扩容。在自动驾驶中，传感器数据通常采用“保留最新”策略，因为过期的点云对实时决策价值有限。

同步通信指调用方发出请求后必须等待响应返回才能继续执行，典型如 RPC 调用。它的优点是逻辑直观、结果确定；缺点是会阻塞线程，在实时系统中容易造成延迟累积。异步通信则指发送方把消息交给中间件后立即返回，不等待处理结果，由回调、Future 或独立线程处理响应。Apollo 的 Cyber RT 框架大量采用异步发布订阅，以保证高频率传感器数据不阻塞主流程。

三、消息持久化与确认机制

在实时系统中，消息并非总是“发出去就完事”。持久化指将消息写入磁盘或持久化存储，使得系统重启、进程崩溃后消息不丢失。Apollo 中，关键日志、回放数据、故障现场信息通常需要持久化；而高频传感器流为了性能，往往只保留在内存队列中。确认机制（ACK）则用于保证消息被成功接收：消费者处理完消息后向中间件发送确认，若超时未确认，中间件会重传。常见的可靠性等级包括“至多一次”“至少一次”和“恰好一次”，分别对应不同的性能与一致性权衡。

四、案例场景：感知到规划的链路

以 Apollo 城市道路场景为例：激光雷达驱动以 10Hz 发布 /apollo/sensor/lidar 点云，感知模块订阅后执行检测与分割，输出障碍物列表到 /apollo/perception/obstacles；规划模块再订阅该主题，生成轨迹并发布到 /apollo/planning；控制模块最终消费轨迹并输出底盘指令。整条链路中，每个主题都可能有多个订阅者，例如预测模块也会订阅障碍物信息。若某个消费者处理过慢，队列会积压，此时“保留最新”策略可以避免系统被历史数据拖垮。

# Apollo Cyber RT 中创建发布者与订阅者的典型写法
writer = node.create_writer("/apollo/perception/obstacles", Obstacles)
reader = node.create_reader("/apollo/perception/obstacles", callback)

# 发布消息
writer.write(obstacles_msg)

# 订阅回调
def callback(msg):
    # 处理障碍物消息
    plan(msg)

五、常见误区与复盘

• 误区一：所有消息都必须持久化。高频传感器流持久化会带来巨大 I/O 压力，应根据数据重要性和频率分级处理。
• 误区二：异步一定优于同步。异步虽然不阻塞，但会引入回调复杂性和时序不确定性；控制指令等需要确定结果的场景仍适合同步。
• 误区三：发布订阅没有背压问题。订阅者处理慢时，消息会堆积；必须设计队列上限、丢弃策略或流控机制。
• 误区四：ACK 等于消息一定被处理。ACK 只表示“已接收”，业务处理失败仍需应用层重试或补偿。