4. DDS协议详解：数据空间、全局数据空间、QoS策略、发现机制与RTPS
DDS（Data Distribution Service）在车载中间件里，地位相当特殊。它不是简单的“发布-订阅”库，而是一套完整的数据-centric 通信范式。我最早接触DDS是在一个ADAS项目里，当时需要把激光雷达的点云数据实时分发给多个感知模块。用传统IPC？延迟和耦合度都扛不住。后来切到DDS，才算真正解决了问题。
这一章，我们拆开DDS的核心概念。你理解透了，后面做SOA服务设计时，就知道什么时候该用DDS，什么时候该换别的。
4.1 数据空间与全局数据空间
先搞清楚两个基础概念：数据空间和全局数据空间。
数据空间，说白了就是一个虚拟的“数据池”。每个DDS参与者（Participant）都可以往这个池子里写数据，或者从池子里读数据。数据不是点对点发送的，而是“发布”到空间里，“订阅”者自动收到。
全局数据空间（Global Data Space）则是跨网络、跨节点的统一视图。不管你的ECU在车上哪个位置，只要加入了同一个域（Domain），大家看到的数据空间就是一致的。这有点像分布式共享内存，但DDS做得更灵活。
关键区别：数据空间是逻辑概念，全局数据空间是物理实现。全局数据空间通过RTPS协议，把多个节点上的数据空间同步成一个整体。
我在项目中遇到过一个问题：两个域ID不同的节点，明明网络通了，但就是收不到对方的数据。排查了半天，发现是Domain ID没对齐。记住，Domain ID是全局数据空间的“门牌号”，对不上就进不了同一个空间。
4.2 QoS策略：DDS的灵魂
DDS之所以强大，很大程度上归功于QoS（Quality of Service）策略。它不是简单的“优先级”，而是一组可配置的策略，控制数据的可靠性、时效性、持久性等行为。
我习惯把QoS分成三类：
| 类别 | 策略名称 | 作用 | 典型场景 |
|---|---|---|---|
| 可靠性 | RELIABILITY | 是否保证数据送达 | 控制指令（RELIABLE） vs 传感器流（BEST_EFFORT） |
| 时效性 | DEADLINE | 数据更新的最大间隔 | 周期信号（如车速每10ms必须更新一次） |
| 持久性 | DURABILITY | 晚加入的订阅者能否收到历史数据 | 配置参数（TRANSIENT_LOCAL） vs 实时数据（VOLATILE） |
| 资源控制 | RESOURCE_LIMITS | 限制缓存样本数 | 防止内存溢出 |
| 生命周期 | LIFESPAN | 数据有效时间 | 过期数据自动丢弃 |
我的经验：QoS配置不是越多越好。我见过有人把RELIABILITY和DEADLINE同时设成最严格，结果网络抖动时系统直接崩溃。建议先按最宽松的策略调通，再逐步收紧。
举个例子，一个摄像头数据流：
// 摄像头发布者QoS配置
QosPolicy qos;
qos.reliability.kind = BEST_EFFORT; // 丢几帧没关系，延迟要低
qos.deadline.period = Duration(33ms); // 30fps，约33ms一帧
qos.durability.kind = VOLATILE; // 不需要历史数据
qos.resource_limits.max_samples = 10; // 最多缓存10帧而一个刹车指令：
// 刹车指令QoS配置
QosPolicy qos;
qos.reliability.kind = RELIABLE; // 必须送达
qos.deadline.period = Duration(10ms); // 10ms内必须收到确认
qos.durability.kind = TRANSIENT_LOCAL; // 新节点加入也能拿到最新指令
qos.lifespan.duration = Duration(100ms); // 100ms后指令失效你看，同样的DDS，不同的QoS配置，行为天差地别。这就是DDS的灵活性，也是它的复杂度所在。
4.3 发现机制：自动握手
DDS的发现机制，解决了“谁在哪、发什么、收什么”的问题。它不需要中心服务器，完全去中心化。
发现机制分两步：
- 参与者发现（Participant Discovery）：节点上线后，通过UDP广播或SPDP（Simple Participant Discovery Protocol）找到其他参与者。
- 端点发现（Endpoint Discovery）：参与者之间交换各自的Topic、数据类型、QoS信息，建立匹配关系。
我曾经在一个项目里，发现两个节点明明在同一个域，但就是匹配不上。查了半天，原来是Topic名称大小写不一致。DDS的Topic匹配是精确字符串匹配，多一个空格都不行。
避坑指南：我曾经在生产环境中遇到一个问题——节点数量超过100个时，发现时间从秒级飙升到分钟级。原因是默认的发现协议是广播，网络拥塞严重。后来改用发现服务器（Discovery Server）模式，才解决了大规模部署的问题。
4.4 RTPS协议：DDS的“运输层”
RTPS（Real-Time Publish-Subscribe Protocol）是DDS的线协议。它定义了数据在网络上怎么打包、怎么传输、怎么确认。DDS规范本身是API层面的，RTPS才是真正跑在网线上的东西。
RTPS的核心组件：
- Writer：数据发布者，负责把数据序列化并发送。
- Reader：数据订阅者，负责接收并反序列化数据。
- Cache：每个Writer/Reader都有自己的缓存，用于存储历史数据。
- Change：一次数据更新的最小单位，包含序列号和时间戳。
RTPS的通信流程：
- Writer产生一个Change，写入自己的Cache。
- RTPS协议将Change打包成报文，通过UDP或TCP发送。
- Reader收到报文，反序列化后放入自己的Cache。
- 应用层从Reader的Cache中读取数据。
你想想看，这个过程和传统的“客户端-服务器”模式完全不同。没有中心节点，没有单点故障。每个节点都是对等的。
4.5 知识结构图：DDS核心逻辑
下面这张图，把DDS的核心概念串起来了。你对照着看，会清晰很多。
4.6 实战建议：什么时候用DDS？
DDS不是银弹。我见过有人把DDS用在简单的信号传输上，结果引入的复杂度远大于收益。我的建议是：
- 适合用DDS的场景：多对多通信、动态拓扑、需要QoS保障（如实时性、可靠性）、跨平台/跨语言。
- 不适合用DDS的场景：简单的请求-响应（用SOME/IP更轻）、单播通信、资源极度受限的MCU。
小技巧：在车载项目中，我习惯把DDS用于传感器数据流和状态发布，而把SOME/IP用于服务调用。两者互补，而不是替代。
嗯，这一章的内容就到这里。DDS的核心概念你掌握了，后面讲具体适配时，你会理解得更深。