4. QoS 核心策略总览
DDS 的 QoS 并不是一组零散的开关，而是一套围绕“数据能否到达、到达多少、何时到达、谁说了算、节点是否还活着”构建的策略体系。理解 QoS 的关键，是先按作用域把策略分成几类：可靠性类决定传输保证，缓存与历史类决定数据保留多少，时间约束类决定数据的新鲜度与时效，所有权类决定多写者冲突时谁生效，活性类决定系统如何感知节点失效。只有把策略放回这些类别中，才能避免“只调 Reliability 却解决不了丢包”的常见误区。
一、核心原理：QoS 是“契约”，不是“配置”
DDS 的 QoS 本质上是发布端与订阅端之间的一份通信契约。发布端声明自己“能提供什么”（Offered），订阅端声明自己“需要什么”（Requested）。中间件在建立关联时逐项比较：只有当订阅端的要求不高于发布端的承诺时，关联才能建立。例如发布端提供 RELIABLE，订阅端要求 BEST_EFFORT，可以匹配；反过来则无法匹配。这一机制决定了 QoS 不是单方面调优，而是两端协商的结果。
从作用域看，QoS 策略可分为三类：发布端策略（Reliability、History、Depth、Durability）、订阅端策略（Liveliness、Time-Based Filter、Resource Limits）、两端匹配策略（Deadline、Latency Budget、Ownership）。理解这个分类，是排查“为什么数据没收到”的第一步。
二、方法流程：按场景选择 QoS 组合
实际工程中，QoS 很少单独使用，而是按场景成组配置。以下是一个典型的选型流程：
- 确定数据重要性：关键控制指令用 RELIABLE，高频传感器数据可用 BEST_EFFORT。
- 确定数据保留需求：需要补发历史数据时，Durability 设为 TRANSIENT_LOCAL 或 PERSISTENT，History 设为 KEEP_ALL 或 KEEP_LAST 并指定 Depth。
- 确定时间约束：周期性数据设置 Deadline，实时控制设置 Latency Budget。
- 确定多写者关系：同一 Topic 有多个发布者时，用 Ownership + Ownership Strength 仲裁。
- 确定失效检测：用 Liveliness + Lease Duration 监控发布者存活。
典型配置示例（IDL 风格伪代码）：
DataWriterQos dw_qos;
dw_qos.reliability.kind = RELIABLE_RELIABILITY_QOS;
dw_qos.history.kind = KEEP_LAST_HISTORY_QOS;
dw_qos.history.depth = 10;
dw_qos.durability.kind = TRANSIENT_LOCAL_DURABILITY_QOS;
dw_qos.deadline.period = {0, 100000000}; // 100ms
dw_qos.latency_budget.duration = {0, 20000000}; // 20ms
dw_qos.ownership.kind = EXCLUSIVE_OWNERSHIP_QOS;
dw_qos.ownership_strength.value = 100;
dw_qos.liveliness.kind = AUTOMATIC_LIVELINESS_QOS;
dw_qos.liveliness.lease_duration = {1, 0}; // 1s三、案例场景：自动驾驶域控中的 QoS 组合
在一个典型的自动驾驶域控系统中，不同 Topic 的 QoS 需求差异很大：
| Topic | Reliability | History / Depth | Durability | Deadline | Ownership | Liveliness |
|---|---|---|---|---|---|---|
| 刹车控制指令 | RELIABLE | KEEP_ALL | TRANSIENT_LOCAL | 10ms | EXCLUSIVE (Strength=200) | MANUAL_BY_TOPIC, 200ms |
| 激光雷达点云 | BEST_EFFORT | KEEP_LAST, Depth=1 | VOLATILE | 100ms | SHARED | AUTOMATIC, 1s |
| 车辆状态反馈 | RELIABLE | KEEP_LAST, Depth=5 | TRANSIENT_LOCAL | 50ms | SHARED | AUTOMATIC, 500ms |
| 地图更新通知 | RELIABLE | KEEP_ALL | PERSISTENT | — | SHARED | AUTOMATIC, 2s |
可以看到，刹车控制指令要求最高：RELIABLE 保证不丢，KEEP_ALL 保留全部历史，TRANSIENT_LOCAL 让晚加入的节点也能拿到最近指令，Deadline 10ms 强制更新频率，EXCLUSIVE + 高 Strength 确保只有一个主控生效，MANUAL_BY_TOPIC 的 Liveliness 让订阅端能快速感知主控失效。而激光雷达点云则相反：BEST_EFFORT 允许丢帧，Depth=1 只保留最新一帧，VOLATILE 不补历史，因为旧点云没有价值。
四、误区与复盘
误区一：只调 Reliability 就能解决丢包。如果 History 设为 KEEP_LAST 且 Depth 过小，即使 RELIABLE 也会因为缓存溢出而丢弃旧数据。Reliability 保证的是“已发送且未被确认的数据会重传”，而不是“无限缓存”。
误区二：Durability 设为 PERSISTENT 就一定能补数据。PERSISTENT 需要持久化存储支持，且订阅端的 Durability 要求不能高于发布端。如果订阅端要求 PERSISTENT 而发布端只提供 TRANSIENT_LOCAL，关联直接失败。
误区三：Deadline 和 Latency Budget 是一回事。Deadline 是“更新周期承诺”，超时触发 DEADLINE_MISSED 状态；Latency Budget 是“传输延迟上限”，是给中间件调度用的提示，不直接触发状态。两者作用不同，不能互相替代。
误区四：Liveliness 只影响发布端。Liveliness 是发布端声明“我还活着”的方式，订阅端通过 Lease Duration 检测超时。如果发布端没有按时发送心跳，订阅端会收到 LIVELINESS_CHANGED 状态，认为发布者已失效。
复盘时建议按以下清单逐项检查：
- 发布端 Offered 是否 ≥ 订阅端 Requested？
- History 与 Depth 是否匹配数据速率和缓存容量？
- Durability 是否与持久化存储能力一致？
- Deadline 是否与数据实际更新周期匹配？
- Ownership Strength 是否在多个发布者之间正确分配？
- Liveliness Lease Duration 是否小于故障检测容忍时间？
- Resource Limits 是否设置了合理的 max_samples 和 max_instances？
QoS 策略总览的价值在于：它把“通信可靠性”拆解成可独立配置、可组合、可验证的维度。掌握这些维度的分类与作用，才能在车载 DDS 系统中构建出既可靠又高效的通信链路。