Fast DDS中TCP传输在高负载场景下的阻塞问题分析与优化

问题背景

在Fast DDS分布式系统中，当使用TCPv4传输协议并配置为可靠传输模式时，如果同时存在大量数据写入者和读取者（例如1000个主题及对应的1000个写入者/读取者），系统可能会出现通信阻塞现象。具体表现为应用程序完全停止响应，无法通过常规方式终止，且CPU使用率降至零。

问题根源分析

这种阻塞现象的根本原因在于TCP协议的流量控制机制与Fast DDS的可靠性保证之间的相互作用：

1. TCP缓冲区溢出：当消息写入速率持续超过消息处理速率时，TCP发送缓冲区会逐渐填满。一旦达到操作系统设置的缓冲区大小上限，TCP协议栈将阻止进一步的数据发送。

2. 可靠性保证的副作用：在可靠传输模式下，Fast DDS需要确保每条消息都能被正确接收和确认。当TCP缓冲区满导致消息无法发送时，系统会进入等待状态，期望缓冲区空间释放后继续发送，从而形成死锁。

3. 系统资源限制：默认的TCP缓冲区大小可能不足以应对高并发、大数据量的场景，特别是在短时间内有大量发现消息需要交换的情况下。

解决方案

1. 启用非阻塞发送模式

通过设置TCP传输描述符的non_blocking_send属性为true，可以避免系统在TCP缓冲区满时进入阻塞状态：

auto descriptor_tmp = std::make_shared<eprosima::fastdds::rtps::TCPv4TransportDescriptor>();
descriptor_tmp->non_blocking_send = true;

工作原理：

• 当TCP缓冲区满时，新的消息发送请求会立即失败而不是阻塞等待
• Fast DDS的可靠性机制会自动重试发送未被确认的消息
• 系统保持响应性，可以继续处理其他任务

注意事项：

• 需要确保数据写入者的历史记录深度足够大，能够保存待重传的消息
• 实际吞吐量可能会因为频繁的重试而有所下降

2. 调整TCP缓冲区大小

增加TCP发送和接收缓冲区的大小可以延缓缓冲区填满的时间：

descriptor_tmp->receiveBufferSize = 1000000;  // 1MB接收缓冲区
descriptor_tmp->sendBufferSize = 1000000;     // 1MB发送缓冲区

系统级配置：

• 需要同时调整操作系统级别的TCP缓冲区大小限制
• 在Linux系统中，可以通过修改/proc/sys/net/core/rmem_max和/proc/sys/net/core/wmem_max等参数

3. 综合优化建议

对于高负载场景的最佳实践：

1. 结合使用非阻塞发送和适当大小的缓冲区
2. 根据实际消息大小和频率计算所需的缓冲区大小
3. 监控系统的消息积压情况，动态调整参数
4. 考虑使用更高效的发现机制或减少不必要的发现流量

性能权衡

在可靠性和系统响应性之间需要做出适当权衡：

• 严格可靠性：可能面临系统阻塞风险，适合对延迟不敏感但对数据完整性要求极高的场景
• 非阻塞模式：保证系统响应性，但可能增加端到端延迟，适合需要实时响应的场景
• 缓冲区大小：较大的缓冲区可以吸收突发流量，但会占用更多内存资源

结论

Fast DDS在高并发场景下使用TCP可靠传输时，合理配置传输参数至关重要。通过启用非阻塞发送模式和优化TCP缓冲区大小，可以有效避免系统阻塞问题，同时保持数据的可靠传输。实际应用中应根据具体场景需求进行参数调优，在系统资源使用、响应时间和数据可靠性之间找到最佳平衡点。