分布式消息队列RocketMQ与Kafka的18项差异之“拨乱反正”

我们知道，阿里的RocketMQ其实源自Kafka。同时网络上一直流传着1篇阿里中间件团队所写的RocketMQ与Kafka的18项差异的文章，并且被广泛转发。比如：

http://blog.csdn.net/damacheng/article/details/42846549

https://yq.aliyun.com/articles/25389

作为对Kafka有一点研究的爱好者，认为这18项差异有“断章取义”之嫌。本着严禁的科学精神，本文试图对这18个条款进行逐一剖析。有不正确之处，欢迎批评指正。

差异之1–”数据可靠性”问题

(1)Kafka只支持异步replication？

结论：Kafka不仅支持异步replication，也支持同步replication，也就是：等消息同步到所有副本之后，再返回给客户端成功。

具体细节，可以参考我之前写的Kakfa源码分析序列，配置ack参数即可实现同步复制。

(2)Kafka只支持异步刷盘？

结论：缺省Kafka是异步刷盘，每3s钟，调用1次fsync。但Kafka支持同步刷盘，也就是说，你可以每写入1条消息，就刷盘1次。

具体细节，参考我写的Kafka源码分析序列，Log文件结构和刷盘原理那1节。同样，也是配置一个log的参数即可。

(3)Kafka的可靠性解决办法–集群思路

那为什么Kafka缺省使用了异步刷盘呢，不怕丢数据吗？其实不是。

Kafka其实是用集群的思路，每个topic_partition多个备份（你可以保证这多个备份是完全一致的）。一台机器挂了，因为数据在page cache里面，会丢；但多个备份同时挂的可能性，就很小了。

所以关于“可靠性”的对比，不能光是“单机”的思路。

差异之2– “性能问题“

原文之中比较kafka和RocketMQ的性能的时候，个人认为不是在一个维度上比较。

要比较性能，不能1个是“同步复制”，一个是“异步复制”来比较，这样没有可比性。

要比较，大家都“同步复制”“同步刷盘”；或者大家都“异步复制”，“异步刷盘”来比。

因为“性能”和“可靠性”本来就是一对权衡的因素，不能牺牲一个，来比另一个。

差异之3 – “消息投递实时性”

Kafka从0.8以后，就开始支持long pull。所以在实时性上，2者并无差别。

差异之4 – “消费失败重试”

这个也就是exactly once问题，关于这个，我在Kafka源码分析的序列1中，就有探讨。

关于这个问题，Kafka的确不处理，而是让消费的业务方去处理，并给出了相应的解决方案。

差异之5 – “严格的消息顺序”

原文中说：“卡夫卡支持消息顺序，但是一台代理宕机后，就会产生消息乱序”。

个人认为这个是断章取义，如果你是异步复制，可能乱序。

但对于同1个partition，只要你是同步复制，该partition在多个副本上，是完全一致的。一个宕机，切换到另一个，不会产生消息乱序。

其他

其他诸如“事务消息”，“定时消息“，“消息查询”，“消息轨迹”，”按时间的消息回朔“，这些Kafka的确没有。

个人认为这些功能可能是RocketMQ针对“电商”的特定业务场景所产生的，而Kafka没有这么强的业务针对性，所以没有考虑这些特定功能。

但没有这些特定功能，不代表业务方不能自己解决这些问题。只是说，针对这些特定场景，RocketMQ做了些高阶功能，从而业务方可以少做一些事情。

关于这些特定功能，以及没有这些特定功能的话，业务方如何自己解决。后续会在“RocketMQ”源码序列中，一一详细阐述。