三大消息中间件的区别

三大消息中间件的区别

首先从五个方面对比三大消息中间件的区别

特性	RabbitMQ	RocketMQ	kafka
开发语言	erlang	Java	scala
单机吞吐量	万级	10万级	10万级
时效性	us级	ms级	ms级
可用性	高(主从架构)	非常高(分布式架构)	非常高(分布式架构)
功能特性	基于erlang开发，所以并发能力很强，性能极其好，延时很低;管理界面较丰富	MQ功能比较完备，扩展性佳	只支持主要的MQ功能，像一些消息查询，消息回溯等功能没有提供，毕竟是为大数据准备的，在大数据领域应用广。

性能方面

RocketMQ和Kafka性能指标在一个级别，RabbitMQ消息堆积后性能不好。

RocketMQ

RocketMQ所有消息都会写入到broker的最新commitLog中，也就是同一个broker的消息不管哪个topic都会把数据写到同一个commitLog文件中，写入后异步生成索引文件ConsumeQueue(commitLog offset, size, tag hash)，ConsumeQueue是以Topic下的queueId为维度的。

Kafka

而Kafka是对于每个topic下的不同partition都有不同数据文件和稀疏哈希索引文件。

这就可以看出，kafka因为做了分拆，通常来说其写入性能肯定是要高于rocketMQ的（写一个文件和多线程写N个文件，都是IO操作，肯定写多个文件总吞吐量大），但是一旦partition过多，kafka就要在单位时间内同时写很多个不同partition的数据文件，出现性能瓶颈。当然kafka还有其他针对高吞吐量场景的nb优化：比如用提高一点点发送端延迟（linger.ms）的代价积攒消息就可以成批投递、这一波积攒的消息在生产者（ProducerBatch内）就可以完成消息的序列化，等发到broker时连解析都不用、正因为broker不需要解析，kafka可以充分发挥协处理器（DMA）优势，利用os的#sendfile直接完成消息的持久化。

RabbitMQ

说说RabbitMQ，为啥堆积性能不好呢？

在RabbitMQ中，不管是内存消息还是持久化消息，数据文件和索引文件都有可能存在磁盘或内存中，这具体取决于内存负载。具体存在什么位置不是一成不变的，这就造成消费时的复杂性，新的消息可能被挤压到很深的backing_queue中，造成消息查找处理时间更长，情况会继续恶化。另外就是集群模式上，如果采用镜像集群，写入存在放大风险，集群内节点越多，所需要同步的数据次数就越多，磁盘IO也会变高。所以追求性能最好采用普通集群模式，并且设置磁盘节点不要太多。

独家特性

RabbitMQ

因为遵循规则，RabbitMQ支持多种协议多种语言，实时推送、mqtt协议、websocket等等，通过插件在html上用js就能接消息，所以在国外脚本语言及全栈盛行的环境下，RabbitMQ对RocketMQ有压倒性人气优势。另外，RabbitMQ支持多级优先级消息，Rabbit通过队列设置就可以让消息的投递和消费有了二叉堆优先级的感觉，这个功能对于Kafka和RocketMQ来说，只能是拒绝三连，其他MQ产品只能通过设置不同topic曲线实现。

RocketMQ/Kafka

用RocketMQ的事务消息搞分布式事务已经被列为最简单的八股文范畴了，原理也就是改变要投递的topic为内建半消息topic，等事务提交了又给你塞回原始topic然后回调。不过就这么点事另外两个MQ还真干不了。kafka和rabbitMQ支持的事务消息更像是保证自己消息中间件的事务性，防止部分消息丢失的策略

首先，准备开启一个事务：
RocketMQ直接封装原始消息、改topic、半消息送入broker一气呵成。
kafka生产者直接向事务协调者发起请求，消息协调者记录到日志。但是。。。这里记录的是kafka开启事务的意愿，记录个状态，和原消息无关。

其次，执行本地事务。
rocket producer端执行本地事务...
kafka生产者发送消息1、发送消息2...

最后，MQ提交/回滚
RocketMQ生产者发送事务提交/回滚请求到Broker，记录到op topic（相当于标记half topic中消息已经处理），提交则把原消息发回到目标topic使得对消费者可见。
kafka的生产者向协调器发出 提交/回滚 请求，协调器去对应日志中标记。
对于一段时间没有commit/rollback的消息，Kafka没有类似RocketMQ的回查机制。

综合上面的材料得出以下几点：

(1)相较于中小型公司，使用RabbitMQ较为推荐，一方面，erlang语言天生具备高并发的特性，而且他的管理界面用起来十分方便。正所谓，成也萧何，败也萧何！他的弊端也在这里，虽然RabbitMQ是开源的，然而国内有几个能定制化开发erlang的程序员呢？所幸，RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug，这点对于中小型公司来说十分重要。不考虑rocketmq和kafka的原因是，一方面中小型软件公司不如互联网公司，数据量没那么大，选消息中间件，应首选功能比较完备的，所以kafka排除。不考虑rocketmq的原因是，rocketmq是阿里出品，如果阿里放弃维护rocketmq，中小型公司一般抽不出人来进行rocketmq的定制化开发，因此不推荐。

(2)大型软件公司，根据具体使用在rocketMq和kafka之间二选一。一方面，大型软件公司，具备足够的资金搭建分布式环境，也具备足够大的数据量。针对rocketMQ,大型软件公司也可以抽出人手对rocketMQ进行定制化开发，毕竟国内有能力改JAVA源码的人，还是相当多的。至于kafka，根据业务场景选择，如果有日志采集功能，肯定是首选kafka了。具体该选哪个，看使用场景。

(3)日志采集、大数据用Kafka，没有非常海量的话，调优下RocketMQ也能用。

(4)日常业务开发我直接RocketMQ，群众基础好、应用范围广、功能丰富，还能实现分布式事务，买1送2。

(5)推送场景、协议复杂、IM领域、急需优先级消息就RabbitMQ，也很成熟。