在高并發業務場景下，典型的阿里雙11秒殺等業務，消息隊列中間件在流量削峰、解耦上有不可替代的作用。

今天我們一起來探討：

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。

10. Pulsar：是 Apache 軟件基金會頂級項目，是下一代云原生分布式消息流平臺，集消息、存儲、輕量化函數式計算為一體，采用計算與存儲分離架構設計。
    

二、MQ消息隊列的技術應用

1.解耦

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

2.最終一致性

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

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

2.廣播

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

有了消息隊列，我們只需要關心消息是否送達了隊列，至于誰希望訂閱，是下游的事情，無疑極大地減少了開發和聯調的工作量。

3.錯峰與流控

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

由于篇幅的關系，本文重點介紹消息隊列比較，詳細應用場景可參考我的往期文章《什么是流量消峰？如何解決秒殺業務的削峰場景》。

三、Kafka、RocketMQ、RabbitMQ比較

1.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. 社區更新較慢；
   

2.RabbitMQ

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

RabbitMQ優點：

1. 由于erlang語言的特性，mq 性能較好，高并發；

2. 吞吐量到萬級，MQ功能比較完備 
   

3. 健壯、穩定、易用、跨平臺、支持多種語言、文檔齊全；

4. 開源提供的管理界面非常棒，用起來很好用

5. 社區活躍度高；

RabbitMQ缺點：

1. erlang開發，很難去看懂源碼，基本職能依賴于開源社區的快速維護和修復bug，不利于做二次開發和維護。

2. RabbitMQ確實吞吐量會低一些，這是因為他做的實現機制比較重。

3. 需要學習比較復雜的接口和協議，學習和維護成本較高。

3.RocketMQ

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

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

RocketMQ優點：

1. 單機吞吐量：十萬級

2. 可用性：非常高，分布式架構

3. 消息可靠性：經過參數優化配置，消息可以做到0丟失

4. 功能支持：MQ功能較為完善，還是分布式的，擴展性好

5. 支持10億級別的消息堆積，不會因為堆積導致性能下降

6. 源碼是java，我們可以自己閱讀源碼，定制自己公司的MQ，可以掌控

RocketMQ缺點：

1. 支持的客戶端語言不多，目前是java及c++等；

2. 社區活躍度一般

   
   

四、消息隊列選擇建議

1.Kafka

Kafka主要特點是追求高吞吐量，一開始的目的就是用于日志收集和傳輸，適合產生大量數據的互聯網服務的數據收集業務。

大型公司建議可以選用，如果有日志采集功能，肯定是首選kafka了。

2.RocketMQ

天生為金融互聯網領域而生，對于可靠性要求很高的場景，尤其是電商里面的訂單扣款，以及業務削峰，在大量交易涌入時，后端可能無法及時處理的情況。

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

3.RabbitMQ

RabbitMQ :結合erlang語言本身的并發優勢，性能較好，社區活躍度也比較高，但是不利于做二次開發和維護。不過，RabbitMQ的社區十分活躍，可以解決開發過程中遇到的bug。

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

閱讀原文：原文鏈接