KafkaRabbitMQ                                                                                                                   英文原文：Benchmarking Message Queue Latency                        

在一年半之前，我宣布了一篇叫分析音讯行列的博客，外面剖析了一些分歧的音讯系统，而且做了一些功能测试。这篇文章如今看起来有点无邪，而且存在非常多问题，可是这倒是我第一次做如许的系统测试，同时我也发明怎么准确的做如许的系统测试是好不容易的，非常多人也做错了。我并非想改正甚么，只是在过来的一年半多的时间里，我学到了非常多，而且测验考试开发了一些好用的Tools，从而丰厚了我的办法论。

Tools和办法论

分析音讯行列的测试运用了一个我开发的框架，它可以有效地触发指定命量的音讯，接纳音讯，同时记载端到真个延迟。这中间有几个问题，起首，负载的发生和耗费是在统一台机械长进行的；其次，测试的运转与剖析的客户端也运转在统一台机械上，这形成了却果的禁绝确；另有，这类“开足马力”，然后看后果延迟的方法其实不能代表真实的生产情况（像Gil Tene爱好说的，这就像是将汽车跑到最快，然后撞到杆上再去看保险杠的外形一样，它们都会很蹩脚）；最初，后果记载的是均匀延迟，这在各类状况下，都是没有效的目标。

我写了Flotilla用来主动实行“可扩大”的测试——行列程序和实行测试的客户端在自力的、分歧的虚拟机长进行。Flotilla会试图依据延迟的分步状况得出一个较好的延迟后果，固然它只能测到99%，可是这足够发明一些暗藏较深的缺点，前面我们就会看到。固然如许，它仍是会满负载的去运转测试，这就不太好了。

Bench则是用来测试一些根底的工具。它就是一个容易、往常的用来权衡延迟的规范测试库，它直接供给了一个恳求接口，用来在分歧的系统下运转。Bench收回必定频率的恳求，然后同步地测试每一个恳求的延迟。延迟经过HDR Histogram实行捕获，它捕获完好的延迟散布，然后将其可视化到“6个9”。

在针抵消息行列的测试中，我们不只需求存眷分歧恳求速度和音讯体巨细抵消息延迟基准测试发生的影响，还需留意时间同步问题。在大大多数基准测试中关怀服务时间而不是呼应时间，可是基于用户的角度思索更应当关怀呼应时间。

最好的方法描绘服务时间和呼应时间是以银行营业为例。想象以下场景，一个银行柜员处置一个客户的营业99%几率下需求30s，1%几率下为3分钟。银行柜员处置一个客户的营业耗时为服务时间。呼应时间为服务时间加入客户等候的时间。别的可以想象呼应时间与服务时间，恳求率相干。当实行音讯行列的基准延迟测试时，我们需求丈量呼应时间。

如今，让我们思索下音讯行列的延迟基准测试，我们需求实行以下几步：

1.记载恳求前时间戳t0.

2实行恳求（恳求端需求与Server时间同步）

3.记载恳求完毕时间戳t1 

4.延迟时间为t1 – t0

5.反复上述步调。

这类测试有甚么问题吗？没有，只需我们的恳求契合某种特定恳求调剂的请求。例如，假如我们以一秒一百次恳求的速度发送恳求而且每次恳求占用10 ms的时间来完成，我们的测试后果就十分好。但是，假如一个恳求占用了100 ms来完成，那末这意味着我们在这100 ms内我们只能发送一个恳求，而依照调剂器的计划来讲，我们应当在阿谁窗口期发送10个恳求。其他9个恳求本应当曾经被发送出去的，可是基准测试在退让的状况下有效共同了测试状况下的系统。可现实上，那9个恳求是在等候的——1个等候了100 ms，1个等候了90 ms，1个等候了80 ms，诸如斯类。绝大大多数基准测试不会捕获这些等候的时间，所以他们对后果会有一个极大的影响。下图显示了统一个基准测试在能否在制止和谐系统的状况下的后果（白色是答应，蓝色是制止）：

HDR直方图试图经过当一个恳求落入非预期的区间时添加额定的例子来调剂制止和谐系统的状况。我们也能够经过防止以上状况来容易处理制止和谐的问题——老是依据调剂器来发送恳求。

音讯行列基准测试

我对一些运用了基准的音讯系统做了基准测试——RabbitMQ (3.6.0), Kafka (0.8.2.2 和 0.9.0.0), Redis (2.8.4) pub/sub, and NATS (0.7.3)。在文章中，"恳求"包括了发布音讯给Server和等候Server的应对的进程(亦即：一个往返进程)。我们测验考试以一个固定的速度发送恳求而且制止系统和谐，以后绘制完好的延迟时间准确到99.9999.%的比例。我们在调剂恳求速度和恳求巨细的设置装备摆设状况下反复实行了几回测试。留意到，没一个音讯从Server发送憾サ回是有一个特定的巨细的，亦即，前往的巨细和恳求是一样的。

我们运用的分歧设置装备摆设以下所示，每个设置装备摆设状况都不断运转了30秒。

• 在3,000恳求/秒的速度下的256B巨细的恳求(768 KB/s)

• 在3,000恳求/秒的速度下的1KB巨细的恳求(3 MB/s)

• 在2,000恳求/秒的速度下的5KB巨细的恳求(10 MB/s)

• 在20,000恳求/秒的速度下的1KB巨细的恳求(20.48 MB/s)

• 在100恳求/秒的速度下的1MB巨细的恳求(100 MB/s)

这些音讯的巨细简直是恣意的，或许会有更好的办法来实行这些测试。

虽然我以为指出以太网最大传输单位室 1500 字节是有需要的，所以思索到音讯头的状况，你能在一个TCP包中传输的最大数据数目应当在1400字节到1500字节之间。

禁受测试和基准测试的客户端运转在两个分歧的m4.xlarge EC2实例上(2.4 GHz Intel Xeon Haswell，16GB RAM)，随同有初级收集(enhanced networking)使能。

Redis 和 NATS

Redis pub/sub 和 NATS 有着类似的表示属性。两者都有着十分轻量级的，非事务性的音讯传输机制随同有不保持(no persistence)选项(不思索Redis 的RDB和AOF保持，这二者不实用于发布定阅机制pub/sub),而且二者都支撑某种水平上的主题形式适配。我关于称恣意一个为传统意义上的“音讯行列”是犹疑的，所以我凡是只是把他们叫做音讯中间人(brokers)或者总线(buses)。由于它们转眼即逝的特征，二者都是低延迟，有消耗传输音讯的不错的选择。

Redis的尾延迟在1.5ms的时分到达峰值

NATS的表示看起来和Redis半斤八两。延迟顶峰在1.2ms摆布

二者的类似性在我们重合1KB和5KB测试散布的时分愈加分明。NATS偏向于快约莫0.1至0.4 ms

1KB，20,000恳求每秒的状况会运用到25个并发衔接。在有兵书负载的状况下，尾延迟急速递增，在%99.9999的精度下辨别在90ms和120ms到达峰值，对应NATS和Redis

关于大音讯体（1MB）的支撑欠好，如图所示NATS和redis辨别在95%line和97%line时有大的尾延迟。1MB是NATS默许的最大音讯巨细。延迟的顶峰为214ms。再次,请记着这些是同步的,往复延迟。

爱立信Apcera平台的 Ivan Kozlovic 指出测试运用的NATS客户端版本不包括比来的功能调优。之前,协议剖析器扫描每一个字节的内容（有效负荷）,可是新版本跳过这部分（之前的基准测试运用的是更新后的新版本）。以下图所示，调优有不言而喻的后果。当音讯体的巨细为5KB时功能晋升了30%。分歧的是在音讯体为1 MB时愈加分明，在90%line功能晋升了约90%。图标中的线性标尺暗藏了这一现实，可是在90%line时，举个例子有优化前延迟为10ms，优惠后延迟为3.8ms。可是明显,大的尾延迟大多是不受优化影响的。

总之，如上所述NATS和redis合适在音讯体小（远低于1MB）的状况下运用，在该情形下99.99%line的音讯延迟在毫秒级。

RabbitMQ和Kafka

RabbitMQ非常盛行，是在AMQP协议下的完成。分歧于NATS，它是传统的音讯行列，支撑行列绑定、事物通报等特征。因而，RabbitMQ绝对来说比较分量级，关于延迟的思索也执偾额定的任务。在测试中，运用了非耐久化行列，因为不需求写到磁盘，延迟也会下降。

在99.7%的时分，延迟还在毫秒以下，可是我们也能够看到，在1KB和5KB音讯负载的状况下，99.7%以后就不如NATS了。

Kafka需求应用磁盘耐久化，可是直到94%时，都没有看出比RabbitMQ分明的延迟。写操作应当是做了页面缓存，然后异步写到磁盘。下面的图片在0.8.2.2版本实行测试。

再一次的，1KB巨细的数据在20,000恳求每秒的状况下散布在25个并发衔接中。在RadbbitMQ中，我们看到了在Redis和NATS中一样的尾延迟的急速增加。RabbitMQ在并发状况下比照之前的延迟到达大约99%的精度下时，它的延迟不断坚持着直线而不是增加。风趣的是，Kafka，表示的仿佛没有被分明地影响。在20,000恳求每秒每恳求巨细为1KB的状况下，延迟和在3,000恳求每秒每恳求巨细为1KB的状况下并没有太大的分歧，都在大约250 ms的状况下到达峰值。

特殊成心思的是1MB音讯巨细时表示的状况和其他状况的比照。在RabbitMQ中，在最大延迟率在5KB音讯巨细和1MB音讯巨细比照时大约有14x的分歧，1MB数据巨细跑得更快。而在Kafka 0.8.2.2中，在统一个标的目的上巨细差异多达126x以上。我们可以用点绘制RabbitMQ 和 Kafka在1MB数据大侠下的延迟由于很难对这类状况实行线性拟合。

我测验考试去了解为何形成了这个反响。针对RabbitMQ，我还没有找到一个公道的说明。直觉通知我是缓存的缘由，在操作系统级别有或者是大音讯体形成了缓存更频仍的冲刷。虽然不成否定我的Rabbit的外部构件常识是有限的，可是记的这些基准测试是瞬态发布的，这应当不会形成硬盘拜访。这类状况只发作在RadditMQ（指有磁盘拜访的状况），没有发作在Redis和NATS中，这仿佛很奇异。一切的基准测试中都禁用了Nagle的算法（TCP_NODELAY），经过Wireshark反省数据包，没有呈现延迟acks的状况。

下图显示了差别是何等地惊人，我们把针对Kafka 0.8.2.2 和 RabbitMQ ，音讯体巨细1MB的测试场景的基准测试的延迟后果与针对Redis和NATS，音讯体5KB巨细的测试场景的基准测试的延迟后果实行比照，它们根本类似。 不管甚么缘由，RabbitMQ和kafka比拟Redis和NATS在大音讯体的处置上都愈加优良。

本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。                        2KB翻译任务按照 CC 协议，假如我们的任务有进犯到您的权益，请实时联络我们。                    

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务