RabbitMQ、Kafka、RocketMQ的優劣勢

今天咱們一塊兒來探討：

1.  全量的消息隊列究竟有哪些？
2.  Kafka、RocketMQ、RabbitMQ的優劣勢比較
3.  以及消息隊列的選型

最全MQ消息隊列有哪些

那麼目前在業界有哪些比較知名的消息引擎呢？以下圖所示

這裏面幾乎徹底列舉了當下比較知名的消息引擎，包括：

1.  ZeroMQ
2.  推特的Distributedlog
3.  ActiveMQ：Apache旗下的老牌消息引擎
4.  RabbitMQ、Kafka：AMQP的默認實現。
5.  RocketMQ
6.  Artemis：Apache的ActiveMQ下的子項目
7.  Apollo：一樣爲Apache的ActiveMQ的子項目的號稱下一代消息引擎
8.  商業化的消息引擎IronMQ
9.  以及實現了JMS(Java Message Service)標準的OpenMQ。

MQ消息隊列的技術應用

1.解耦

解耦是消息隊列要解決的最本質問題。

2.最終一致性

最終一致性指的是兩個系統的狀態保持一致，要麼都成功，要麼都失敗。

最終一致性不是消息隊列的必備特性，但確實能夠依靠消息隊列來作最終一致性的事情。

2.廣播

消息隊列的基本功能之一是進行廣播。

有了消息隊列，咱們只須要關心消息是否送達了隊列，至於誰但願訂閱，是下游的事情，無疑極大地減小了開發和聯調的工做量。

3.錯峯與流控

典型的使用場景就是秒殺業務用於流量削峯場景。

因爲篇幅的關係，本文重點介紹消息隊列比較，詳細應用場景請參考：什麼是流量削峯？如何解決秒殺業務的削峯場景

 

 

Kafka、RocketMQ、RabbitMQ比較

1.ActiveMQ

優勢

•  單機吞吐量：萬級
•  topic數量都吞吐量的影響：
•  時效性：ms級
•  可用性：高，基於主從架構實現高可用性
•  消息可靠性：有較低的機率丟失數據
•  功能支持：MQ領域的功能極其完備

缺點:

 

官方社區如今對ActiveMQ 5.x維護愈來愈少，較少在大規模吞吐的場景中使用。

2.Kafka

號稱大數據的殺手鐗，談到大數據領域內的消息傳輸，則繞不開Kafka，這款爲大數據而生的消息中間件，以其百萬級TPS的吞吐量名聲大噪，迅速成爲大數據領域的寵兒，在數據採集、傳輸、存儲的過程當中發揮着舉足輕重的做用。

Apache Kafka它最初由LinkedIn公司基於獨特的設計實現爲一個分佈式的提交日誌系統( a distributed commit log)，以後成爲Apache項目的一部分。

目前已經被LinkedIn，Uber, Twitter, Netflix等大公司所採納。

 

優勢

•  性能卓越，單機寫入TPS約在百萬條/秒，最大的優勢，就是吞吐量高。
•  時效性：ms級
•  可用性：很是高，kafka是分佈式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會致使不可用
•  消費者採用Pull方式獲取消息, 消息有序, 經過控制可以保證全部消息被消費且僅被消費一次;
•  有優秀的第三方Kafka Web管理界面Kafka-Manager；
•  在日誌領域比較成熟，被多家公司和多個開源項目使用；
•  功能支持：功能較爲簡單，主要支持簡單的MQ功能，在大數據領域的實時計算以及日誌採集被大規模使用

缺點：

1.  Kafka單機超過64個隊列/分區，Load會發生明顯的飆高現象，隊列越多，load越高，發送消息響應時間變長
2.  使用短輪詢方式，實時性取決於輪詢間隔時間；
3.  消費失敗不支持重試；
4.  支持消息順序，可是一臺代理宕機後，就會產生消息亂序；
5.  社區更新較慢；

3.RabbitMQ

RabbitMQ 2007年發佈，是一個在AMQP(高級消息隊列協議)基礎上完成的，可複用的企業消息系統，是當前最主流的消息中間件之一。

 

RabbitMQ優勢：

1.  因爲erlang語言的特性，mq 性能較好，高併發；
2.  吞吐量到萬級，MQ功能比較完備  
3.  健壯、穩定、易用、跨平臺、支持多種語言、文檔齊全；
4.  開源提供的管理界面很是棒，用起來很好用  
5.  社區活躍度高；

RabbitMQ缺點：

1.  erlang開發，很難去看懂源碼，基本職能依賴於開源社區的快速維護和修復bug，不利於作二次開發和維護。
2.  RabbitMQ確實吞吐量會低一些，這是由於他作的實現機制比較重。  
3.  須要學習比較複雜的接口和協議，學習和維護成本較高。

 

4.RocketMQ

RocketMQ出自 阿里公司的開源產品，用 Java 語言實現，在設計時參考了 Kafka，並作出了本身的一些改進。

RocketMQ在阿里集團被普遍應用在訂單，交易，充值，流計算，消息推送，日誌流式處理，binglog分發等場景。

 

RocketMQ優勢：

1.  單機吞吐量：十萬級
2.  可用性：很是高，分佈式架構
3.  消息可靠性：通過參數優化配置，消息能夠作到0丟失
4.  功能支持：MQ功能較爲完善，仍是分佈式的，擴展性好
5.  支持10億級別的消息堆積，不會由於堆積致使性能降低
6.  源碼是java，咱們能夠本身閱讀源碼，定製本身公司的MQ，能夠掌控 

RocketMQ缺點：

1.  支持的客戶端語言很少，目前是java及c++，其中c++不成熟；
2.  社區活躍度通常
3.  沒有在 mq 核心中去實現JMS等接口，有些系統要遷移須要修改大量代碼 

 

消息隊列選擇建議

 

1.Kafka

Kafka主要特色是基於Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用於日誌收集和傳輸，適合產生大量數據的互聯網服務的數據收集業務。

大型公司建議能夠選用，若是有日誌採集功能，確定是首選kafka了。

 

2.RocketMQ

天生爲金融互聯網領域而生，對於可靠性要求很高的場景，尤爲是電商裏面的訂單扣款，以及業務削峯，在大量交易涌入時，後端可能沒法及時處理的狀況。

RoketMQ在穩定性上可能更值得信賴，這些業務場景在阿里雙11已經經歷了屢次考驗，若是你的業務有上述併發場景，建議能夠選擇RocketMQ。

 

3.RabbitMQ

RabbitMQ :結合erlang語言自己的併發優點，性能較好，社區活躍度也比較高，可是不利於作二次開發和維護。不過，RabbitMQ的社區十分活躍，能夠解決開發過程當中遇到的bug。

若是你的數據量沒有那麼大，小公司優先選擇功能比較完備的RabbitMQ。