4、DDS服务质量策略：QoS概述、可靠性策略、持久性策略、截止时间策略、生命周期策略
4.1 QoS概述：为什么我们需要“服务质量”？
聊到DDS，绕不开的一个核心话题就是QoS。QoS的全称是Quality of Service，中文叫服务质量。说白了，它就是一套用来定义数据如何被发送、接收和存储的规则集合。
我经常跟团队里的年轻人讲，没有QoS的DDS就像没有交通规则的高速公路。车（数据）虽然能跑，但谁先走、谁后走、走丢了怎么办、超时了怎么处理，全凭运气。这在汽车上可不行，对吧？
DDS标准里定义了二十多种QoS策略。但说实话，在汽车SOA（面向服务的架构）项目中，我们常用的也就那么七八种。今天咱们重点聊四个最关键的：可靠性、持久性、截止时间和生命周期。
核心观点：QoS不是越多越好，而是越匹配越好。选错了QoS，轻则性能下降，重则系统崩溃。我在一个项目中就见过因为可靠性策略设置不当，导致整个域控制器CPU飙到100%的情况。
4.2 可靠性策略：你的数据真的到了吗？
可靠性策略，英文叫Reliability。它解决的是一个问题：数据到底要不要保证送达？
DDS提供了两种模式：
- BEST_EFFORT（尽力而为）：发送方只管发，不管收没收到。丢了就丢了，不重传。
- RELIABLE（可靠）：发送方会确认接收方是否收到，没收到就重传，直到确认收到为止。
你可能会问，那是不是所有场景都用RELIABLE就行了？嗯，这里要注意。RELIABLE是有代价的。它需要维护状态、需要确认机制、需要重传缓冲区。如果网络质量不好，重传风暴能把系统拖垮。
我个人习惯这样划分：
| 场景 | 推荐策略 | 原因 |
|---|---|---|
| 传感器数据（如摄像头、雷达） | BEST_EFFORT | 数据量大，偶尔丢一帧不影响，重传反而增加延迟 |
| 控制指令（如刹车、转向） | RELIABLE | 指令丢了可能出安全事故，必须保证送达 |
| 状态信息（如车速、档位） | BEST_EFFORT | 状态是持续更新的，丢了等下一帧就行 |
| 诊断日志 | RELIABLE | 诊断数据需要完整，不能丢 |
避坑指南：我曾经在一个项目中，把所有Topic都设成了RELIABLE。结果呢？摄像头数据因为网络抖动开始疯狂重传，导致CPU占用率飙升，ADAS功能直接卡死。后来改成BEST_EFFORT，问题立刻解决。记住：不是所有数据都值得“可靠”。
4.3 持久性策略：数据能活多久？
持久性策略，英文叫Durability。它解决的是：晚来的订阅者，能不能看到之前发布的数据？
举个例子。你车上的某个服务节点启动比较慢，等它启动完成时，其他节点已经发了好几轮数据了。如果没有持久性策略，这个晚来的节点就永远错过了那些数据。
DDS定义了三种持久性级别：
- VOLATILE（易失）：不保存任何历史数据。新订阅者只能看到它加入之后发布的数据。
- TRANSIENT_LOCAL（本地临时）：数据保存在发送方的内存中。只要发送方还在运行，新订阅者就能获取到历史数据。
- TRANSIENT（临时）：数据保存在DDS中间件的缓存中，不依赖发送方是否存活。
- PERSISTENT（持久）：数据持久化到磁盘，即使系统重启，数据依然存在。
在汽车项目中，我建议这样选：
对于大多数实时控制数据，用VOLATILE就够了。为什么？因为数据更新频率高，晚来一帧无所谓，等下一帧就行。
但对于一些配置信息、参数表这类数据，我建议用TRANSIENT_LOCAL。我记得有一次做OTA升级，升级后的配置参数需要广播给所有节点。有些节点正在休眠，醒来后如果没有持久化数据，就会用旧配置，导致功能异常。后来改成TRANSIENT_LOCAL，问题就解决了。
注意：PERSISTENT级别在汽车上很少用。因为写入磁盘的延迟太高，而且频繁写盘会缩短Flash寿命。除非是黑匣子数据或者关键日志，否则别碰它。
4.4 截止时间策略：你的数据超时了吗？
截止时间策略，英文叫Deadline。它解决的是：数据必须在规定时间内到达，否则就算失败。
这个策略很有意思。它不保证数据一定能按时到，但它会告诉你：“嘿，数据超时了！”
怎么用呢？发布者和订阅者各自设置一个Deadline周期。如果发布者在这个周期内没有发布新数据，或者订阅者在这个周期内没有收到新数据，DDS就会触发一个回调函数，通知应用层“超时了”。
我举个例子。在自适应巡航（ACC）系统中，前向雷达需要以50ms的周期发送目标数据。如果超过50ms没收到数据，控制器必须立即进入降级模式，比如提示驾驶员接管。这时候Deadline策略就派上用场了。
// 伪代码示例：设置Deadline策略
DDS::DeadlineQosPolicy deadline;
deadline.period.sec = 0;
deadline.period.nanosec = 50000000; // 50ms
// 发布者设置
DataWriterQos writer_qos;
writer_qos.deadline = deadline;
// 订阅者设置
DataReaderQos reader_qos;
reader_qos.deadline = deadline;
// 监听超时事件
void on_deadline_missed(DataReader* reader,
const DeadlineMissedStatus& status) {
// 进入降级模式
enter_degraded_mode();
log_warning("雷达数据超时！");
}关键点：Deadline策略的周期设置要合理。设得太短，网络抖动就会频繁触发超时；设得太长，又失去了监控的意义。我一般建议设置为正常发布周期的1.5到2倍。比如50ms的发布周期，Deadline设75ms或100ms比较合适。
4.5 生命周期策略：数据什么时候该“死”？
生命周期策略，英文叫Lifespan。它解决的是：数据在缓存里能待多久？过期了怎么办？
你想想看，有些数据是有时效性的。比如车辆的位置信息，5秒前的数据还有意义吗？如果订阅者处理不过来，数据在队列里堆积，等它被处理时，车辆可能已经开出几百米了。
Lifespan策略就是给数据设置一个“保质期”。超过这个时间，DDS会自动丢弃这条数据，不让它被订阅者读到。
我建议这样用：
- 高频传感器数据：Lifespan设短一些，比如100ms-500ms。过期了就别处理了，等下一帧。
- 低频状态数据：Lifespan可以设长一些，比如几秒甚至几十秒。
- 配置参数：Lifespan可以设得很长，甚至不设限制。
这里有个坑。我曾经在一个项目中，把Lifespan设得特别长，结果订阅者处理速度跟不上，队列里堆满了旧数据。新数据反而进不来，导致系统响应越来越慢。后来把Lifespan缩短到200ms，队列里的数据自动过期丢弃，系统就恢复正常了。
小技巧：Lifespan和History策略（历史数据深度）要配合使用。如果History深度设得大，Lifespan又设得长，内存占用会很高。我一般习惯：高频数据用“深度1+Lifespan短”，低频数据用“深度大+Lifespan长”。
4.6 总结：QoS策略的搭配思路
好了，四种核心QoS策略咱们都过了一遍。最后我想说，QoS策略不是孤立使用的，它们需要搭配起来才能发挥最大效果。
我给大家一个参考搭配表：
| 应用场景 | Reliability | Durability | Deadline | Lifespan |
|---|---|---|---|---|
| 控制指令 | RELIABLE | VOLATILE | 10ms | 50ms |
| 传感器流数据 | BEST_EFFORT | VOLATILE | 100ms | 200ms |
| 车辆状态 | BEST_EFFORT | TRANSIENT_LOCAL | 500ms | 1s |
| 配置参数 | RELIABLE | TRANSIENT_LOCAL | 无 | 无限制 |
| 诊断日志 | RELIABLE | TRANSIENT | 1s | 10s |
记住一句话：QoS是为业务服务的，不是为技术服务的。先搞清楚你的数据是什么性质，再决定用什么策略。别为了用QoS而用QoS，那样只会把系统搞复杂。
下一章，咱们聊聊DDS的发现机制和动态通信。到时候见。