2、DDS核心概念：数据空间、域、域参与者、主题、发布者、订阅者、数据写入者、数据读取者

好，我们直接进入正题。DDS这套东西，刚接触的人容易懵——概念太多了。我当年第一次看OMG的规范文档，说实话，看了三遍才理清楚谁是谁。今天咱们就把这些核心概念一个一个拆开，用我实际项目里的经验帮你串起来。

2.1 数据空间（Data Space）—— 全局数据池

数据空间，说白了就是一个虚拟的、全局共享的数据池子。你想想看，在传统的ECU架构里，A模块想拿B模块的数据，得走CAN信号或者RPC调用，麻烦得很。DDS的做法是：所有节点都把数据扔进这个「空间」里，谁需要谁取。

我在做智能驾驶域控项目时，经常跟团队说一句话：「别把数据当成私有财产，它属于数据空间。」这个思维转变很重要。数据空间没有物理边界，它就是一个逻辑概念，但它是DDS一切通信的基础。

核心要点：数据空间是DDS通信的「虚拟总线」，所有数据都在这里流动。它不关心数据从哪里来、到哪里去，只负责提供「发布-订阅」的媒介。

2.2 域（Domain）—— 通信的隔离边界

域这个概念，我建议你把它理解成「独立的通信房间」。一个域就是一个独立的DDS通信平面，不同域之间的数据是完全隔离的。为什么要这么设计？

举个例子。在我之前做的座舱域控项目中，有娱乐系统、仪表系统、HUD系统。这三个系统虽然都在同一台硬件上跑，但我不希望娱乐系统的音乐播放状态影响到仪表的安全告警。怎么办？把它们分到不同的域里。

域ID 用途 典型数据
0 车辆控制域 车速、转向、制动
1 智能驾驶域 感知结果、规划路径
2 座舱娱乐域 媒体状态、语音指令

嗯，这里要注意：域ID是一个16位整数，范围0~232。同一个域内的参与者才能互相通信。我见过有人把所有的服务都塞到域0里，结果调试时数据乱飞——这就是没用好域的隔离特性。

2.3 域参与者（DomainParticipant）—— 域的入口

域参与者，你可以把它当成「进入这个域的通行证」。任何一个DDS应用程序，想要在某个域里收发数据，必须先创建一个域参与者对象。

我个人习惯把域参与者比作「应用程序在DDS世界里的身份ID」。它负责管理这个应用在该域内的所有资源——包括后面要讲的主题、发布者、订阅者等等。

// 伪代码示例：创建域参与者
DomainParticipant* participant = 
    DomainParticipantFactory::get_instance()->create_participant(
        0,  // 域ID，这里用域0
        PARTICIPANT_QOS_DEFAULT,
        nullptr,
        StatusMask::none()
    );

我在项目中遇到过一个问题：两个模块明明都在域0里，但就是收不到对方的数据。查了半天，发现是域参与者的QoS配置不一致——一个用了默认配置，另一个自定义了分区策略。所以记住：域参与者是入口，但入口的「规则」（QoS）必须对齐。

2.4 主题（Topic）—— 数据的名字标签

主题，就是数据的名字。每个在数据空间里流动的数据，都必须有一个主题来标识它是什么。比如「/vehicle/speed」这个主题，一看就知道是车速数据。

主题的定义包含三要素：主题名 + 数据类型 + QoS。主题名是字符串，数据类型是你定义的IDL结构体，QoS决定了这个主题的通信行为。

我的经验：主题命名一定要规范。我见过有人用「topic1」「data2」这种名字，三个月后自己都看不懂。建议用类似文件路径的命名方式，比如「/sensor/lidar/pointcloud」。

2.5 发布者（Publisher）与数据写入者（DataWriter）

这两个概念经常被搞混。我简单说：发布者是管理者，数据写入者是执行者。

  • 发布者（Publisher）：负责管理一组数据写入者。它决定这些写入者用什么策略来发送数据，比如是否批量发送、是否使用异步写入。
  • 数据写入者（DataWriter）：真正干活的。它绑定到一个具体的主题上，应用程序通过它把数据写入数据空间。

你想想看，一个发布者可以管理多个数据写入者。比如一个传感器融合模块，它有一个发布者，下面挂了三个数据写入者——分别写「/sensor/camera」「/sensor/lidar」「/sensor/radar」三个主题。

// 伪代码：创建发布者和数据写入者
Publisher* publisher = participant->create_publisher(
    PUBLISHER_QOS_DEFAULT,
    nullptr,
    StatusMask::none()
);

DataWriter* writer = publisher->create_datawriter(
    topic,  // 绑定到主题
    DATAWRITER_QOS_DEFAULT,
    nullptr,
    StatusMask::none()
);

避坑指南：我曾经在项目中犯过一个错——每个数据写入者都单独创建一个发布者。结果系统里发布了上百个发布者实例，资源开销巨大。后来改成「一个模块一个发布者，多个数据写入者」，性能提升明显。记住：发布者是资源管理器，别滥用。

2.6 订阅者（Subscriber）与数据读取者（DataReader）

跟发布端对称，订阅端也分两层：订阅者是管理者，数据读取者是执行者。

  • 订阅者（Subscriber）：管理一组数据读取者。它决定数据到达后的处理策略，比如是回调通知还是轮询读取。
  • 数据读取者（DataReader）：绑定到主题，从数据空间里读取数据。它维护一个本地的数据缓存队列，应用程序从中取数据。

说白了，数据读取者就是你的「数据接收窗口」。每个数据读取者只关心一个主题的数据。如果你想同时收车速和方向盘角度，那就得创建两个数据读取者。

// 伪代码：创建订阅者和数据读取者
Subscriber* subscriber = participant->create_subscriber(
    SUBSCRIBER_QOS_DEFAULT,
    nullptr,
    StatusMask::none()
);

DataReader* reader = subscriber->create_datareader(
    topic,
    DATAREADER_QOS_DEFAULT,
    nullptr,
    StatusMask::none()
);

2.7 它们之间的关系——一张图说清楚

我习惯用「公司」的比喻来理解这些概念：

  • 数据空间 = 整个公司的办公大楼
  • 域 = 大楼里的不同楼层（财务部、研发部互不干扰）
  • 域参与者 = 你的工牌（有了它才能进楼层）
  • 主题 = 文件柜上的标签（「销售报表」「技术文档」）
  • 发布者 = 部门文员（管理谁负责送文件）
  • 数据写入者 = 送文件的人（把文件放进对应的文件柜）
  • 订阅者 = 部门前台（管理谁负责收文件）
  • 数据读取者 = 收文件的人（从文件柜里取出文件）

这个比喻虽然简单，但核心逻辑是对的。我在给团队做培训时就用这套比喻，新人理解起来快很多。

2.8 小结

好了，这一章的内容就这些。核心就一句话：DDS的通信模型是「分层管理、职责分离」。发布者/订阅者负责管理策略，数据写入者/数据读取者负责实际的数据搬运。主题是数据的标签，域是隔离的边界，域参与者是你的入场券。

下一章我们会深入讲QoS——这才是DDS真正强大的地方。到时候我会拿我踩过的坑来举例，保证让你印象深刻。

← 上一章 📖 返回目录 下一章 →