0. 引言

高要求的分布式系统催生了对轻量级且高性能中间件的需求。在现有的选项中，ZeroMQ 和 Fast-DDS 是高性能的异步中间件，采用发布-订阅模式。

主要优点包括：

• 性能：更好的延迟和吞吐量。数据在可用时立即发送。
• 高度解耦：无需周期性请求数据，订阅者只需声明对数据更新的兴趣即可。

ZeroMQ 是一种消息中间件，不需要消息代理，并实现了多种通信模式，包括发布-订阅和请求-响应。消息的序列化和反序列化需要用户自己实现。其API类似于套接字库。

Fast-DDS 是实时发布订阅协议（RTPS）的高性能实现，提供了简单的发布-订阅API。该产品通过从接口定义语言（IDL）生成代码的方式提供序列化支持，并包含一个超快速的序列化库：eProsima FastCDR。

1. 目标：ZeroMQ与Fast-DDS性能对比

本次测试的目标是测量并比较在使用发布-订阅模式下，Fast-DDS与ZeroMQ的延迟和吞吐量。Fast-DDS使用eProsima FastCDR进行数据序列化，这是一款非常快速的序列化引擎。

需要考虑的差异

Fast-DDS和ZeroMQ之间有一些差异需要分析。

• 传输协议：Fast-DDS支持TCP和UDP，而默认使用TCP；ZeroMQ使用TCP。Fast-DDS的UDP模式包含自己的ACK/NACK可靠性协议，支持单播和多播。
• 协议头：另一个直接影响性能的重要差异是每个协议的头部。RTPS是一个更加多功能的协议，设计用于在无可靠性的协议上实现。它还具备许多其他功能（如键控主题、顺序传递等），因此其头部更大。从测试结果中可以看到，ZeroMQ在处理非常小的消息时稍微优于Fast-DDS，这很可能是由于较小的头部导致的。
• 节点发现：发现机制也是一个需要考虑的因素。Fast-DDS带有内置的端点发现机制。用户只需指定主题名称和数据类型，如果QoS兼容，中间件会自动匹配发布者和订阅者，这使得设置和配置更加简单。然而，ZeroMQ没有这样的机制，用户需要手动设置发布者和订阅者的IP地址以实现通信。

2. ZeroMQ vs Fast-DDS - 延迟基准测试

2.1 一对一发布-订阅延迟

一对一订阅延迟的对比见下图：

在小消息大小的情况下，ZeroMQ的延迟略优。然而，随着消息大小的增加，Fast-DDS的延迟优于ZeroMQ。两者都表现出相似的线性行为，但Fast-DDS的斜率更小。

如前所述，ZeroMQ在消息大小在16到128字节之间时表现出更小的延迟。这种现象最可能的解释是ØMQ消息的头部比RTPS消息的头部更小。随着消息大小的增加，头部大小的重要性下降，因为它在传输数据中所占比例变小。

2.2 一对多发布-订阅延迟

相同的测试也在有三个订阅者的场景下进行：

在小消息大小的情况下，ZeroMQ和Fast-DDS的延迟非常相似。随着消息大小的增加，使用Fast-DDS和多播广播的优势变得更加明显。对于16K字节大小的消息，延迟差异可高达200微秒。

在这种情况下，ZeroMQ的头部较小的优势因需要向每个订阅者发送相同数据而被抵消。可以看到，在小消息大小情况下，两个实现的延迟值非常相似，这增强了Fast-DDS相对于ZeroMQ的竞争力。随着订阅者数量的增加，ZeroMQ的延迟值可能会明显增加，而Fast-DDS的增长则更缓慢。

3. ZeroMQ vs Fast-DDS - 吞吐量基准测试

下图展示了ZeroMQ与Fast-DDS之间的吞吐量对比：

此图表明，ZeroMQ在处理较小消息大小时能实现更高的吞吐量。这是因为ZeroMQ使用的是TCP，这是一种优化了吞吐量的流协议，而RTPS主要是为实时性能而设计的，使用了无连接的UDP。

然而，随着消息大小的增加，Fast-DDS开始表现出更高的吞吐量，并最终超过ZeroMQ。这是因为Fast-DDS的序列化和传输算法在大消息的情况下比ZeroMQ更为有效。对于高负载场景，Fast-DDS成为更优的选择。

4. 方法论

延迟

延迟通常定义为消息穿越系统所需的时间。在基于数据包的网络中，延迟通常被测量为单程延迟（从源节点发送数据包到目的节点接收数据包的时间）或往返延迟（从源节点到目的节点的时间加上从目的节点返回到源节点的时间）。后者更常用，因为它可以从一个点测量。

在RTPS通信交换中，延迟可以定义为发布者序列化并发送数据消息所需的时间，加上匹配的订阅者接收并反序列化消息所需的时间。应用之前提到的往返概念，往返延迟可以定义为消息由发布者发送，订阅者接收并发送回发布者的时间。例如，在下图中，往返时间将是T2-T1，延迟为(T2-T1)/2。

在多个订阅者场景中，测量延迟采用类似的过程。在这种情况下，发布者将数据发送给两个订阅者，但只有一个对消息做出响应。类似地，延迟也计算为(T2-T1)/2。

吞吐量

在通信网络中，吞吐量通常定义为通过通信通道成功传输消息的速率。吞吐量通常以字节每秒来表示。有多种方法可以测量通信网络的吞吐量。最常见的方法是发送一个大文件（或多个较小文件），然后测量将其传输到网络的另一个点所需的时间，之后将数据量除以传输所需的时间。

在RTPS通信的情况下，可以通过在一定时间内发送一组消息来测量吞吐量，并获取传输数据的总大小。然而，为了获得最大吞吐量值，必须尝试不同的消息需求（D - 连续发送的消息数量），以找到最佳值，即最大化发布者的可用发送通道而不会导致订阅者接收队列溢出（造成数据包丢失）。下面的图表展示了进行此测试的过程：

当然，吞吐量可以在发布者端（发送了多少数据）和订阅者端（接收了多少数据）进行测量。如果没有数据包丢失，两个值将非常相似，值之间的微小差异将由时间测量的差异引起。然而，如果数据包丢失，则吞吐量值将根据不同的端点而有所不同。为了建立一个可靠的测量规则，我们将假设每个消息大小的最大吞吐量为在发布者端测量的值，前提是订阅者端没有数据包丢失。

5. 结论

两者均展示了非常优越的性能，但在特定情况下有所不同：

• 小消息：ZeroMQ通常在处理小消息（如控制指令、状态更新等）时表现更好，特别是在需要高吞吐量的情况下。
• 大消息与多订阅者场景：Fast-DDS在处理大消息时具有优势，特别是在多订阅者场景中，其多播支持表现出色。它还具有更加灵活且自动化的节点发现和匹配机制，降低了用户配置的复杂性。

最终选择哪种中间件，取决于你的系统的具体需求：是小消息和高吞吐量，还是大消息和更好的多播支持。

6. 参考

本文内容数据引用自zmq-vs-eprosima-fast-rtps,原文已不能访问。本文是通过eprosima-zmq-vs-eprosima-fast-rtps访问到的。