Fast DDS 中系统时钟调整导致样本丢失问题分析与解决方案

问题背景

在 Fast DDS 分布式系统中，当系统时钟被调整（无论是手动调整还是由于 NTP 时间同步服务导致）时，订阅者会出现样本丢失的现象。这一问题在系统时钟被回拨到过去时间点时尤为明显，导致后续接收到的样本被错误地丢弃。

问题根源分析

经过深入分析，发现问题主要出在 DataReaderHistory 的实现机制上。具体表现为：

1. 样本比较逻辑缺陷：在 DataReaderHistory::received_change_keep_last 和 DataReaderHistory::completed_change_keep_last 方法中，系统会将新接收样本的 sourceTimestamp 与历史缓存中的第一个样本进行比较。当时钟被回拨后，新样本的时间戳会小于缓存中的样本时间戳，导致样本被错误丢弃。

2. DestinationOrderQoS 策略实现不完整：虽然 Fast DDS 文档中说明默认使用 BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS 策略，但实际实现却更接近于 BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS 的行为，这与预期不符。

3. 系统时钟依赖问题：Fast DDS 多处实现依赖系统时钟，而非稳定的单调时钟，这使得系统对时钟调整非常敏感。

技术影响

这一问题会导致以下严重后果：

1. 数据完整性受损：关键样本被错误丢弃，影响系统可靠性。
2. 调试困难：问题只在特定时钟条件下出现，难以复现和诊断。
3. 系统行为不可预测：时钟同步服务可能导致意外行为。

解决方案演进

开发团队针对此问题提出了多个解决方案迭代：

1. 初始修复方案：修改 current_time_since_unix_epoch 实现，使其基于稳定时钟而非系统时钟。这一方案解决了应用运行期间的时钟调整问题，但存在局限性。

2. 深度修复方案：彻底修改 DataReaderHistory 的样本比较逻辑，不再单纯依赖源时间戳，而是结合写入者 GUID 和序列号进行更智能的判断。

3. 最终解决方案：采用更全面的比较策略，对于同一写入者的样本使用序列号比较，不同写入者间才使用时间戳比较，确保在各种时钟条件下都能正确处理样本。

实现细节

核心修复代码主要修改了样本比较逻辑：

if (change->writerGUID == first_change->writerGUID ? 
    change->sequenceNumber >= first_change->sequenceNumber :
    change->sourceTimestamp >= first_change->sourceTimestamp)
{
    // 处理样本替换逻辑
}

这一修改确保了：

• 同一写入者的样本按序列号排序
• 不同写入者的样本仍能保持时间顺序
• 系统时钟调整不会影响同一写入者样本的处理

最佳实践建议

基于此问题的解决经验，建议开发者在实现分布式系统时：

1. 尽量避免直接依赖系统时钟，优先使用单调时钟。
2. 实现时间相关功能时，考虑时钟回拨等边界情况。
3. 对于关键的时间敏感逻辑，提供可配置的策略选项。
4. 在文档中明确说明时间处理策略和潜在限制。

未来改进方向

Fast DDS 团队计划进一步完善相关功能：

1. 完整实现 DestinationOrderQoS 策略，支持两种排序模式的明确选择。
2. 提供更灵活的时间源配置选项，允许用户自定义时钟实现。
3. 增强对时钟不同步情况的检测和处理能力。

这一问题的解决过程展示了 Fast DDS 团队对系统可靠性的持续追求，也为分布式系统的时间处理提供了有价值的实践经验。