3、DDS通信模型：发布-订阅模式详解、全局数据空间概念、QoS策略概览
好，我们进入DDS的核心地带。
说实话，很多工程师第一次接触DDS，都会被它的概念绕晕。什么全局数据空间、什么QoS策略，听着就头大。但你别怕，这些东西说白了，就是一套非常优雅的通信规则。我当年刚入行时，也觉得这东西太抽象，直到在项目里亲手调过一次，才恍然大悟——原来如此。
3.1 发布-订阅模式：这才是真正的解耦
先聊聊发布-订阅模式。你想想看，传统的通信方式，比如CAN或者以太网的UDP，通常是一对一的。发送方得知道接收方是谁，接收方也得知道数据从哪来。这叫紧耦合。
DDS不一样。它用的是发布-订阅模式。发布者只管把数据扔到“数据空间”里，它根本不需要知道谁在收。订阅者呢，也只管从“数据空间”里拿数据，它也不关心谁在发。
我在项目中遇到过这样一个场景：一个摄像头节点要发图像数据，同时有感知模块、显示模块、记录模块都要用。如果用传统方式，摄像头得维护一个接收方列表，还得处理断连重连。用DDS就简单了——摄像头只管发布，其他模块各自订阅。新增一个模块？不用改摄像头代码，直接加个订阅者就行。
核心要点：发布-订阅模式实现了空间解耦、时间解耦和流量解耦。发布者和订阅者可以不在同一时间运行，也可以在不同网络节点上，甚至可以用不同的速率收发数据。
嗯，这里要注意：DDS的发布-订阅不是简单的“广播”。它是有数据类型的。每个Topic都绑定一个特定的数据结构。比如“车道线数据”这个Topic，它的数据类型就是车道线结构体。订阅者只能收到匹配类型的数据。这比单纯的字节流安全多了。
3.2 全局数据空间：一个虚拟的“数据黑板”
接下来是全局数据空间。这个概念，我建议你把它想象成一个“虚拟黑板”。
所有节点都连接在这个黑板上。发布者往黑板上写数据，订阅者从黑板上读数据。黑板本身不存储数据，它只是一个逻辑概念。真正干活的是DDS中间件，它负责把数据从发布者传到订阅者。
为什么叫“全局”？因为在这个DDS域里，所有节点都能看到这个空间。不管节点在哪个物理机器上，只要它们属于同一个域，并且使用相同的Topic，就能互相通信。
我的经验：在ADAS系统中，我习惯把全局数据空间按功能划分成不同的“域”。比如感知域、规划域、控制域。每个域有自己的数据空间，互不干扰。这样既保证了数据隔离，又方便调试。我曾经在一个项目里把所有数据都放在一个域里，结果调试时数据流乱成一团，后来改成多域设计，清爽多了。
全局数据空间还有一个好处：它天然支持“发现机制”。新节点加入时，DDS会自动发现它，并建立通信链路。不需要手动配置IP地址或端口号。这在ADAS系统里特别实用——你想想，一辆车上几十个ECU，如果每个都要手动配网络参数，那得累死。
3.3 QoS策略概览：DDS的灵魂所在
好了，重头戏来了——QoS策略。
我常说，没有QoS的DDS，就是个高级的UDP。QoS才是DDS的灵魂。它让你能精确控制数据的传输行为。
DDS定义了20多种QoS策略。但别慌，实际项目中常用的就那几种。我给你列个表，一目了然：
| QoS策略 | 作用 | 典型场景 |
|---|---|---|
| RELIABILITY | 可靠性：可靠传输 vs 尽力传输 | 控制指令用可靠，传感器数据用尽力 |
| DURABILITY | 持久性：晚加入的订阅者能否收到历史数据 | 地图数据需要持久，实时感知数据不需要 |
| DEADLINE | 截止时间：数据必须在指定时间内到达 | 制动指令必须在10ms内送达 |
| LIVELINESS | 活性：检测节点是否存活 | 监控关键节点的健康状态 |
| HISTORY | 历史深度：保留最近多少条数据 | 保留最近10帧图像用于回放 |
我重点说说RELIABILITY。这个策略有两个选项：RELIABLE和BEST_EFFORT。
RELIABLE保证数据一定送达。如果丢了，DDS会自动重传。这适合控制指令、配置参数这类关键数据。但代价是延迟会高一些，因为要等待确认。
BEST_EFFORT就不管丢包了。发出去就算完。这适合传感器数据，比如摄像头帧、激光雷达点云。丢一两帧没关系，但延迟必须低。
避坑指南：我曾经在一个项目中，把所有Topic都设成了RELIABLE。结果发现系统延迟飙升，CPU占用率也高得吓人。后来一查，原来是摄像头数据量太大，重传机制把网络堵死了。记住：不是所有数据都需要可靠传输。传感器数据用BEST_EFFORT，控制指令用RELIABLE，这是黄金法则。
再说说DURABILITY。这个策略决定了新加入的订阅者能不能收到之前发布的数据。
比如地图数据。车启动时，地图节点可能已经发布过地图了。如果感知模块启动得晚，它还能收到地图吗？这就要靠DURABILITY。设为TRANSIENT_LOCAL，DDS会为每个订阅者保留一份历史数据。新订阅者加入时，自动收到这份数据。
但实时数据就不需要了。比如当前车速，订阅者只需要最新的值。设为VOLATILE就行，不保留历史。
3.4 QoS组合：没有银弹
你可能会问：这么多QoS策略，怎么组合？
我的建议是：没有银弹。每个系统都不一样。但有个基本原则——QoS策略必须匹配业务需求。
举个例子。ADAS里的“障碍物列表”这个Topic：
- 可靠性：用RELIABLE。障碍物信息不能丢，丢了可能撞车。
- 持久性：用VOLATILE。障碍物是实时数据，旧数据没用。
- 截止时间：设100ms。超过100ms没收到新数据，说明感知模块出问题了。
- 历史深度：KEEP_LAST 1。只保留最新一帧障碍物数据。
你看，每个策略都有它的道理。不是随便选的。
我的习惯：在项目初期，我会先画一张“数据流图”，标出每个Topic的实时性要求、可靠性要求、数据量大小。然后根据这张图，逐个确定QoS策略。这样做的好处是，后期调优时，能快速定位问题。我记得有一次，系统出现偶发性的数据丢失，排查了半天，最后发现是HISTORY策略设得太小，导致数据被覆盖了。改大一点就解决了。
最后，我想说一句：DDS的QoS策略，是它区别于其他中间件的最大优势。但也是最大的坑。用好了，系统稳定高效。用不好，各种奇怪问题都会冒出来。我的建议是：先理解每个策略的含义，再结合业务场景去配置。不要贪多，从最常用的几个策略开始，慢慢积累经验。
嗯，这一节就到这里。下一节我们聊聊DDS的发现机制和动态配置，那也是个很有意思的话题。