📚 课程目录第4章数据通道核心原理

4. 数据通道核心原理

在 Cyber RT 中，数据通道（Channel）是节点之间交换消息的核心抽象。它把“谁发布、谁订阅、消息长什么样、走哪条路传输”这几件事统一封装起来，使上层组件开发只需关注业务逻辑，而不必反复处理底层通信细节。理解 Channel 的创建过程、发布订阅模型、序列化方式以及传输层与共享内存机制，是写出高性能 Cyber RT 组件的前提。

一、Channel 的创建：从节点到通道

Channel 并不是孤立存在的，它依附于节点（Node）和参与者（Participant）。一个典型的创建流程如下：

组件初始化时创建 Node，并指定节点名称与命名空间。
通过 node->CreateWriter<T>(channel_name) 创建发布者，或通过 node->CreateReader<T>(channel_name, callback) 创建订阅者。
Cyber RT 根据通道名称在底层建立对应的 Channel 对象，并注册到传输层。
若同一进程内已有相同通道，则复用底层共享内存或域套接字资源，避免重复创建。

通道名称通常采用 /namespace/topic 形式，例如 /apollo/perception/obstacles。名称不仅是标识，也决定了消息的路由范围。创建 Writer 时，Cyber RT 会为该通道分配一个唯一的 Channel ID，并绑定消息类型信息，用于后续序列化与反序列化。

通道创建的本质是“注册 + 绑定”：注册到传输层，绑定消息类型与传输策略。只有完成这两步，消息才能被正确路由和解析。

二、发布订阅模型：一对多与多对多

Cyber RT 采用典型的发布/订阅（Pub/Sub）模型。发布者（Writer）与订阅者（Reader）之间通过通道名称解耦，彼此不需要知道对方的存在。一个通道可以有一个或多个 Writer，也可以有一个或多个 Reader，形成一对多或多对多的通信关系。

发布订阅模型的关键特性包括：

异步解耦：Writer 发布消息后立即返回，不阻塞等待 Reader 处理。
多播分发：同一通道上的所有 Reader 都能收到消息，互不影响。
回调驱动：Reader 通过注册回调函数处理消息，回调在 Cyber RT 的调度线程中执行。
历史缓存：通道可配置历史消息深度，新加入的 Reader 可选择是否接收历史消息。

下面是一个典型的 Writer 与 Reader 创建示例：

// 创建发布者
auto writer = node->CreateWriter<ObstacleList>("/perception/obstacles");

// 创建订阅者
auto reader = node->CreateReader<ObstacleList>(
    "/perception/obstacles",
    [](const std::shared_ptr<ObstacleList>& msg) {
        // 处理消息
        ProcessObstacles(*msg);
    });

需要注意的是，Reader 的回调执行线程由 Cyber RT 调度器管理。如果回调中执行耗时操作，会阻塞后续消息处理，因此建议在回调中只做轻量级的数据搬运或转发。

三、消息序列化：Protobuf 与传输格式

Cyber RT 默认使用 Protobuf 作为消息序列化格式。消息在发送前被序列化为二进制字节流，接收后再反序列化为对象。序列化的核心作用是：

将结构化数据转换为可跨进程、跨机器传输的字节流。
保证消息在不同语言、不同平台之间的一致性。
通过紧凑的二进制编码减少传输开销。

在 Channel 创建时，消息类型信息会被注册到类型系统。Writer 发送时调用 SerializeToArray，Reader 接收时调用 ParseFromArray。对于共享内存传输，Cyber RT 会尽量避免重复序列化：如果消息已经在共享内存中，Reader 可以直接映射读取，减少一次拷贝和解析。

环节	操作	性能关注点
发送前	Protobuf 序列化为字节流	消息体大小、字段数量
传输中	共享内存或域套接字	拷贝次数、内存映射开销
接收后	反序列化为对象	解析耗时、内存分配
回调前	消息封装为 shared_ptr	引用计数、生命周期管理

四、传输层与共享内存机制

Cyber RT 的传输层根据通信双方的位置自动选择传输方式。同一进程内或同一主机上的不同进程，优先使用共享内存（Shared Memory）；跨主机通信则使用域套接字或网络传输。共享内存机制是 Cyber RT 高性能的关键。

共享内存的核心思想是：Writer 将消息写入一块所有 Reader 都能访问的内存区域，Reader 直接读取该区域，避免内核态与用户态之间的多次拷贝。其典型流程如下：

Writer 申请共享内存块，将序列化后的消息写入。
Writer 更新共享内存中的写指针或状态标志。
Reader 通过内存映射直接访问该内存块，读取消息。
Reader 处理完成后，通过引用计数或确认机制释放内存块。

共享内存机制带来的优势非常明显：零拷贝、低延迟、高吞吐。但它也带来一些约束：消息生命周期由共享内存管理，Reader 不能长期持有消息指针；共享内存块大小有限，超大消息可能退化为其他传输方式。

在组件开发中，如果发现消息延迟异常高，可以优先检查是否命中了共享内存传输。若消息体过大或跨主机，传输层会自动切换为网络传输，延迟会明显上升。

五、案例：感知到规划的障碍物通道

以自动驾驶中“感知到规划”的障碍物通道为例。感知组件创建 Writer，通道名为 /apollo/perception/obstacles，消息类型为 ObstacleList。规划组件创建 Reader，订阅同一通道。两者在同一主机上运行，Cyber RT 自动启用共享内存传输。

感知组件每 100ms 发布一次障碍物列表，规划组件在回调中读取并更新局部地图。由于共享内存零拷贝，规划组件几乎不需要等待数据搬运，端到端延迟可控制在毫秒级。如果规划组件回调中执行了复杂的路径搜索，则会阻塞后续障碍物消息，导致感知数据积压。因此，回调中应只做数据快照，复杂计算放到独立线程或任务队列中。

六、常见误区与复盘

误区一：通道名称随意写。 通道名称是路由的唯一标识，命名混乱会导致订阅不到消息。建议统一使用 /模块/功能 格式。
误区二：在回调中做重计算。 回调线程被阻塞会拖慢整个通道的消息处理，应尽量轻量化。
误区三：认为共享内存一定最快。 共享内存适合小消息、高频场景；超大消息或跨主机时，网络传输反而更稳定。
误区四：忽略消息生命周期。 共享内存中的消息由 Cyber RT 管理，Reader 不应长期持有裸指针，应使用 shared_ptr 或拷贝数据。

调试通道问题时，优先确认三件事：通道名称是否一致、消息类型是否匹配、Writer 与 Reader 是否在同一 Cyber RT 域内。这三项任意一项不匹配，都会导致消息无法送达。

总结来说，Channel 的创建是注册与绑定的过程，发布订阅模型实现了节点间的解耦，Protobuf 序列化保证了消息的跨平台一致性，而传输层与共享内存机制则决定了通信的性能上限。掌握这四者之间的关系，才能在组件开发中合理设计通道、优化回调、控制消息大小，从而构建出低延迟、高吞吐的 Cyber RT 数据通道。