经常使用mq对比及rocketmq、kafka选型

1、经常使用MQ对比

上述来自CSDN搜索博客中的图片。

上述来自阿里云栖社区搜索博客中的图片。

2、rocket、kafka选型

（如下汉字内容是从下述各个网站中摘取出的我的认为的重点内容。）

一、Kafka vs RocketMQ ——消息及时性对比

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

在Kafka里面，Maser/Slave是选举出来的！！！RocketMQ不须要选举！！！

具体来讲，在Kafka里面，Master/Slave的选举，有2步：第1步，先经过ZK在全部机器中，选举出一个KafkaController；第2步，再由这个Controller，决定每一个partition的Master是谁，Slave是谁。

这里的Master/Slave是动态的，也就是说：当Master挂了以后，会有1个Slave切换成Master。

而在RocketMQ中，不须要选举，Master/Slave的角色也是固定的。当一个Master挂了以后，你能够写到其余Master上，但不会说一个Slave切换成Master。

这种简化，使得RocketMQ能够不依赖ZK就很好的管理Topic/queue和物理机器的映射关系了，也实现了高可用。

二、RocketMQ与kafka对比（18项差别）

https://yq.aliyun.com/articles/73165?spm=5176.100239.blogcont62836.34.lxBuKC

淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件，使用Mysql做为消息存储媒介，可彻底水平扩容，为了进一步下降成本，咱们认为存储部分能够进一步优化，2011年初，Linkin开源了Kafka这个优秀的消息中间件，淘宝中间件团队在对Kafka作过充分Review以后，Kafka无限消息堆积，高效的持久化速度吸引了咱们，可是同时发现这个消息系统主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下还有诸多特性不知足，为此咱们从新用Java语言编写了RocketMQ，定位于非日志的可靠消息传输（日志场景也OK），目前RocketMQ在阿里集团被普遍应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

三、Kafka、RabbitMQ、RocketMQ发送小消息性能对比

https://yq.aliyun.com/articles/62831?spm=5176.100239.blogcont62836.16.lxBuKC

不断增长发送端的压力,直到系统吞吐量再也不上升,而响应时间拉长。这时服务端已出现性能瓶颈,能够得到相应的系统最佳吞吐量。

在服务端处理同步发送小消息、无订阅组消费的性能上,Kafka>RocketMQ>RabbitMQ。

四、Kafka vs RocketMQ——Topic数量对单机性能的影响

https://yq.aliyun.com/articles/62832?spm=5176.100239.blogcont62836.17.lxBuKC

不断增长发送端的压力,直到系统吞吐量再也不上升,而响应时间拉长。此时服务端出现性能瓶颈，获取相应的系统最佳吞吐量，整个过程当中保证消息没有累积。

Kafka在Topic数量由64增加到256时，吞吐量降低了 98.37% 。

RocketMQ在Topic数量由64增加到256时，吞吐量只降低了 16% 。

为何两个产品的表现如此悬殊呢？这是由于Kafka的每一个Topic、每一个分区都会对应一个物理文件。当Topic数量增长时，消息分散的落盘策略会致使磁盘IO竞争激烈成为瓶颈。而RocketMQ全部的消息是保存在同一个物理文件中的，Topic和分区数对RocketMQ也只是逻辑概念上的划分，因此Topic数的增长对RocketMQ的性能不会形成太大的影响。

测试结论

在消息发送端，消费端共存的场景下，随着Topic数的增长Kafka吞吐量会急剧降低，而RocketMQ则表现稳定。所以Kafka适合Topic和消费端都比较少的业务场景，而RocketMQ更适合多Topic，多消费端的业务场景。

五、Kafka vs RocketMQ——单机系统可靠性

https://yq.aliyun.com/articles/62833?spm=5176.100239.blogcont62836.19.lxBuKC

测试结论

1. 在Broker进程被Kill的场景， Kafka和RocketMQ都能在保证吞吐量的状况下，不丢消息，可靠性都比较高。

2. 在宿主机掉电的场景，Kafka与RocketMQ均能作到不丢消息，此时Kafka的吞吐量会急剧下跌，几乎不可用。RocketMQ则仍能保持较高的吞吐量。

3. 在单机可靠性方面，RocketMQ综合表现优于Kafka。

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

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

六、万亿级数据洪峰下的分布式消息引擎

https://yq.aliyun.com/articles/165103?spm=5176.100244.teamhomeleft.18.RJbTZr

消息引擎围绕着RocketMQ内核，在阿里内部有三大块：Notify解决事务消息，采用服务端push模型，用于交易核心消息分发；MetaQ用于有序消息，采用pull模型，能够解决海量消息堆积；Aliware MQ是RocketMQ商业版，支持公有云、金融云、私有云、聚石塔。

针对慢请求、长尾效应，阿里给出的解决方案是：低延迟存储，使用预分配+内存锁，读写分离，二次异步；限流、熔断，降级，秒级隔离；多副本高可用机制，Zab、Paxos/Raft，自动/手动切换，容灾演练。