4. DDS QoS策略实战（上）：可靠性、持久性、历史记录、资源限制
各位同学，今天我们正式进入DDS QoS策略的实战环节。说实话，QoS是DDS的灵魂，也是很多人觉得最难啃的骨头。我刚开始接触DDS时，也被这二十多个策略搞得晕头转向。但后来我发现，只要把最核心的几个搞明白，剩下的都是锦上添花。
今天我们先聊四个最常用的策略：可靠性、持久性、历史记录、资源限制。这四个策略，几乎每个ADAS项目都会用到。
4.1 可靠性（Reliability）：数据到底能不能丢？
可靠性策略，说白了就是决定「数据丢了怎么办」。DDS提供了两种模式：BEST_EFFORT（尽力而为）和RELIABLE（可靠）。
我在项目中遇到过这样一个场景：摄像头采集的图像数据，如果丢了一两帧，其实影响不大。但如果是控制指令丢了，那车可能就失控了。你想想看，这能一样吗？
| 策略值 | 行为描述 | 典型场景 |
|---|---|---|
| BEST_EFFORT | 发送方尽力发送，不重传 | 传感器数据、视频流 |
| RELIABLE | 发送方确保接收方收到，自动重传 | 控制指令、状态切换 |
核心原则：控制类数据用RELIABLE，感知类数据用BEST_EFFORT。别搞反了，否则系统性能会出大问题。
代码配置其实很简单，我习惯这样写：
// 可靠性策略配置示例
qos.reliability.kind = RELIABLE_RELIABILITY_QOS;
qos.reliability.max_blocking_time.sec = 1;
qos.reliability.max_blocking_time.nanosec = 0;嗯，这里要注意：max_blocking_time这个参数很关键。它决定了当网络拥堵时，发送方最多等多久。我曾经见过一个项目，把这个时间设成了10秒，结果系统卡死，车辆直接进入安全模式。教训啊！
4.2 持久性（Durability）：晚来的订阅者怎么办？
持久性策略解决的是「后来者」的问题。假设一辆车已经运行了10分钟，这时候一个新的ECU节点上线了。它需要获取之前的数据吗？
DDS提供了三种持久性级别：
- VOLATILE（易失）：新订阅者只能收到之后发布的数据。这是默认行为。
- TRANSIENT_LOCAL（本地临时）：数据保存在发布方内存中，新订阅者可以获取到。
- TRANSIENT（临时）：数据保存在DDS中间件中，不依赖发布方是否在线。
- PERSISTENT（持久）：数据持久化到磁盘，重启后依然可用。
我的建议：ADAS系统中，TRANSIENT_LOCAL用得最多。比如车辆启动时，各个模块需要获取最新的标定参数。用VOLATILE的话，晚来的模块就收不到了。
配置示例：
// 持久性策略配置
qos.durability.kind = TRANSIENT_LOCAL_DURABILITY_QOS;
// 设置数据保存深度
qos.durability.depth = 10;为什么深度要设成10？我个人习惯是，根据数据更新频率来定。如果数据每秒更新100次，深度设10就够了，因为新节点启动后很快就能拿到最新数据。
4.3 历史记录（History）：保留多少旧数据？
历史记录策略和持久性策略经常一起用。它决定了DDS要保留多少历史样本。
两种模式：
- KEEP_LAST：只保留最近N个样本。N由depth参数指定。
- KEEP_ALL：保留所有样本，直到资源耗尽。
警告：千万别在生产环境用KEEP_ALL！我见过一个团队，测试时用了KEEP_ALL，结果内存暴涨，系统直接OOM。ADAS系统内存本来就紧张，你想想看，一个传感器每秒发100帧数据，10分钟就是6万帧，内存能扛得住吗？
正确的做法：
// 历史记录策略配置
qos.history.kind = KEEP_LAST_HISTORY_QOS;
qos.history.depth = 5;深度设多少合适？我一般遵循「够用就好」的原则。控制指令保留最近5条就够了，传感器数据保留1条最新值即可。别贪多。
4.4 资源限制（Resource Limits）：别让内存爆炸
资源限制策略是DDS的「安全阀」。它从三个维度控制资源使用：
| 参数 | 含义 | 建议值 |
|---|---|---|
| max_samples | 最大样本总数 | 根据内存预算计算 |
| max_instances | 最大实例数 | 根据Topic数量设定 |
| max_samples_per_instance | 每个实例最大样本数 | 通常等于history.depth |
配置示例：
// 资源限制策略配置
qos.resource_limits.max_samples = 100;
qos.resource_limits.max_instances = 10;
qos.resource_limits.max_samples_per_instance = 10;避坑指南：我曾经在一个项目中，只配了history.depth，没配resource_limits。结果系统运行一段时间后，内存持续增长。后来发现，虽然history只保留5条，但DDS内部还有其他缓存。所以，history和resource_limits一定要配合使用。
4.5 四个策略的协同配置
这四个策略不是孤立的，它们需要协同工作。我总结了一个配置模板，大家可以参考：
// ADAS系统典型QoS配置
qos.reliability.kind = RELIABLE_RELIABILITY_QOS;
qos.reliability.max_blocking_time.sec = 1;
qos.durability.kind = TRANSIENT_LOCAL_DURABILITY_QOS;
qos.durability.depth = 5;
qos.history.kind = KEEP_LAST_HISTORY_QOS;
qos.history.depth = 5;
qos.resource_limits.max_samples = 50;
qos.resource_limits.max_instances = 10;
qos.resource_limits.max_samples_per_instance = 5;这个配置适用于大多数控制类Topic。如果是传感器数据，把reliability改成BEST_EFFORT，history.depth改成1就行。
小技巧：调试阶段可以把所有参数设得宽松一些，方便排查问题。但上线前一定要收紧，否则系统稳定性会出问题。我一般会在代码里留一个DEBUG宏，调试和生产环境用不同的QoS配置。
好了，今天这四个策略就讲到这里。下节课我们继续聊剩下的几个关键策略：生命周期、所有权、分区等。记住，QoS配置没有银弹，一定要根据实际场景来调。多测试、多验证，才能找到最适合你系统的配置。