常用mq对比及rocketmq、kafka选型

CHSHJ

　　一、常用MQ对比

　　

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

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

　　二、rocket、kafka选型
　　

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

　　

　　1、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和物理机器的映射关系了，也实现了高可用。
　　

　　2、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分发等场景。
　　

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

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

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

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

　　4、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，多消费端的业务场景。
　　

　　5、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同步刷盘的模式，在享受高可靠性保障的同时，又能拥有较高的吞吐量。
　　

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

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

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

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