消息中间件学习总结（13）——Kafka与RocketMQ的单机系统可靠性比较分析

引言

前几期的评测中，我们对比了Kafka和RocketMQ的吞吐量和稳定性，本期我们要引入一个新的评测标准——软件可靠性。

何为“可靠性”？

先看下面这种情况：有A，B两辆越野汽车，在城市的周边地区均能很好应对泥泞的路况。当一同开去穿越西藏，A车会因为西藏本地的汽油不达标，导致油路受阻无法点火，而B车顺利完成了穿越。因此我们说，B车的可靠性比A车高。

何为“软件可靠性”？

“软件的可靠性”就是考察软件在各种异常突发的情况下的应对能力。常见的软件异常有：磁盘损坏、进程意外退出、宿主机宕机等情况。

何为“消息中间件的可靠性”？

对于消息中间件来说，“可靠性”最直接的指标就是——消息数据不丢失。此外，消息不重投、服务一主多备等特性也可以用来评估可靠性。

那么Kafka和RocketMQ（以下简称RMQ）在可靠性上孰优孰劣呢？和我们走进本期的测试比拼吧！

测试目的

在消息收发的过程中，分别模拟Broker服务进程被Kill、物理机器掉电的异常场景，多次实验，查看极端情况下消息系统的可靠性。

测试场景

以下场景使用多个发送端向一个Topic发送消息，发送方式为同步发送，分区数为8，只启动一个订阅者。

场景1. `模拟进程退出`

在消息收发过程中，利用Kill -9 命令使Broker进程终止，然后重新启动，得到可靠性数据如下：

注：以上测试场景中Kafka的异步刷盘间隔为1秒钟，同步发送需设置request.required.acks=1，否则会出现消息丢失。

在Broker进程被终止重启，Kafka和RMQ都能保证同步发送的消息不丢，因为进程退出后操作系统能确保将该进程遗留在内存的数据刷到磁盘上。实验中，Kafka出现了极少量的消息重复。再次可以确定此场景中，二者的可靠性都很高。

场景2. `模拟机器掉电`

在消息收发过程中，直接拔掉Broker所在的宿主机电源，然后重启宿主机和Broker应用。因受到机房断电限制，我们在本场景测试中使用的是普通PC机器。得到可靠性数据如下：

测试发现，即使在并发很低的情况下，Kafka和RMQ都无法保证掉电后不丢消息。这个时候，就需要改变刷盘策略了。我们把刷盘策略由“异步刷盘”变更为“同步刷盘”，就是说，让每一条消息都完成存储后才返回，以保证消息不丢失。
注：关于两种刷盘模式的详细区别可以参照文档最下方的说明

重新执行上面的测试，得到数据如下：

首先，设置同步刷盘时，二者都没出现消息丢失的情况。限于我们使用的是普通PC机器，两者吞吐量都不高。此时Kafka的最高TPS仅有500条/秒，RMQ可以达到4000条/秒，已经是Kafka的8倍。

为什么Kafka的吞吐量如此低呢？因为Kafka本身是没有实现任何同步刷盘机制的，就是说在这种场景下测试，Kafka注定是要丢消息的。但要想做到每一条消息都在落盘后才返回，我们可以通过修改异步刷盘的频率来实现。设置参数log.flush.interval.messages=1，即每条消息都刷一次磁盘。这样的做法，Kafka也不会丢消息了，但是频繁的磁盘读写直接导致性能的下降。

另外，二者在服务恢复后，均出现了消息重复消费的情况，这说明消费位点的提交并不是同步落盘的。不过，幸好Kafka和RMQ都提供了自定义消费位点的接口，来避免大量的重复消费。

测试结论

在Broker进程被Kill的场景， Kafka和RocketMQ都能在保证吞吐量的情况下，不丢消息，可靠性都比较高。
在宿主机掉电的场景，Kafka与RocketMQ均能做到不丢消息，此时Kafka的吞吐量会急剧下跌，几乎不可用。RocketMQ则仍能保持较高的吞吐量。
在单机可靠性方面，RocketMQ综合表现优于Kafka。

附录:

测试环境

服务端为单机部署，机器配置如下：

应用版本：

测试脚本

同步刷盘和异步刷盘的区别

同步刷盘是在每条消息都确认落盘了之后才向发送者返回响应；而异步刷盘中，只要消息保存到Broker的内存就向发送者返回响应，Broker会有专门的线程对内存中的消息进行批量存储。所以异步刷盘的策略下，当机器突然掉电时，Broker内存中的消息因无法刷到磁盘导致丢失。

未完待续

本期测试中，RocketMQ比Kafka具有更高的单机可靠性。对于普通业务，部署异步刷盘模式可以得到更高的性能；对于丢消息零容忍的业务，则更适用RocketMQ同步刷盘的模式，在享受高可靠性保障的同时，又能拥有较高的吞吐量。

实际上，单机可靠性只是软件可靠性测试的一个环节，Kafka和RocketMQ都提供了主备机模式，来解决服务器的单点故障。这点我们在后续会继续实验摸索，敬请期待接下来的比拼！

消息中间件学习总结（13）——Kafka与RocketMQ的单机系统可靠性比较分析相关推荐

消息中间件系列(八)：Kafka、RocketMQ、RabbitMQ等的优劣势比较
在高并发业务场景下,典型的阿里双11秒杀等业务,消息队列中间件在流量削峰.解耦上有不可替代的作用. 之前介绍了MQ消息队列的12点核心原理总结,以及如何从0到1设计一个MQ消息队列,以及RPC远程调用 ...
消息中间件学习总结（3）——RocketMQ之十分钟入门RocketMQ
本文首先引出消息中间件通常需要解决哪些问题,在解决这些问题当中会遇到什么困难,Apache RocketMQ作为阿里开源的一款高性能.高吞吐量的分布式消息中间件否可以解决,规范中如何定义这些问题.然后 ...
消息中间件学习总结（1）——RocketMQ之专访RocketMQ联合创始人：项目思路、技术细节和未来规划
编者按这些年开源氛围越来越好,各大IT公司都纷纷将一些自研代码开源出来.2012年,阿里巴巴开源其自研的第三代分布式消息中间件--RocketMQ.经过几年的技术打磨,阿里称基于RocketMQ技术 ...
消息中间件学习总结（9）——RocketMQ与kafka差异比较分析
淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件,使用Mysql作为消息存储媒介,可完全水平扩容,为了进一步降低成本,我们认为存储部分可以进一步优化,2011年初,Linkin开源了Kaf ...
消息中间件学习总结（6）——RocketMQ之RocketMQ大数据畅想
刚刚过去的双十一,阿里自主研发的消息中间件RocketMQ,充分展现了它的低延迟特性,大部分消息请求落在2ms内,慢请求也都落在20ms内,这无疑给追求快速响应的在线交易系统(OLTP)带去了福音. ...
消息中间件学习总结（5）——RocketMQ之Apache RocketMQ背后的设计思路与最佳实践
摘要:为了更好地让开发者们更加深入了解阿里开源,阿里云云栖社区在3月1号了举办"阿里开源项目最佳实践"在线技术峰会,直播讲述了当前阿里新兴和经典开源项目实战经验以及背后的开发思路. ...
[转载] 消息中间件学习总结（8）——RocketMQ之RocketMQ捐赠给Apache那些鲜为人知的故事
参考链接: 捐赠序言今年的双十一对阿里巴巴中间件消息团队来说,注定是个不平凡的日子.在这一天,稳定性小组重点攻克的低延迟存储解决方案成功地经受住了大考.整个大促期间,99.996%的延迟落在了10 ...
消息中间件学习总结（8）——RocketMQ之RocketMQ捐赠给Apache那些鲜为人知的故事
序言今年的双十一对阿里巴巴中间件消息团队来说,注定是个不平凡的日子.在这一天,稳定性小组重点攻克的低延迟存储解决方案成功地经受住了大考.整个大促期间,99.996%的延迟落在了10ms以内,极个别由 ...
消息中间件学习总结（7）——RocketMQ之万亿级数据洪峰下的分布式消息引擎
前言通过简单回顾阿里中间件(Aliware)消息引擎的发展史,本文开篇于双11消息引擎面临的低延迟挑战,通过经典的应用场景阐述可能会面临的问题 - 响应慢,雪崩,用户体验差,继而交易下跌.为了应对这 ...

消息中间件学习总结（13）——Kafka与RocketMQ的单机系统可靠性比较分析

引言

测试目的