經常使用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，自動/手動切換，容災演練。