MQ（訊息佇列框架）選型對比：ActiveMQ, RabbitMQ, RocketMQ, Kafka
市場使用情況（背景）
-
中小型軟體公司，建議選RabbitMQ。一方面，erlang語言天生具備高併發的特性，而且他的管理介面用起來十分方便。不考慮rocketmq和kafka的原因是，一方面中小型軟體公司不如網際網路公司，資料量沒那麼大，選訊息中介軟體，應首選功能比較完備的，所以kafka排除。RocketMQ也很不錯，只是沒有RabbitMQ出來的早，文件和網上的資料沒有RabbitMQ多，但也是很不錯，RocketMQ是阿里出品，現在阿里已經把RocketMQ捐贈給Apache了，維護和更新不是問題 。
-
大型軟體公司，根據具體使用在rocketMq和kafka之間二選一。一方面，大型軟體公司，具備足夠的資金搭建分散式環境，也具備足夠大的資料量。針對rocketMQ,大型軟體公司也可以抽出人手對rocketMQ進行定製化開發，畢竟國內有能力改JAVA原始碼的人，還是相當多的。至於kafka，根據業務場景選擇，如果有日誌採集功能，肯定是首選kafka了。具體該選哪個，看使用場景
橫縱對比
- ActiveMQ
優點
單機吞吐量：萬級
topic數量都吞吐量的影響：
時效性：ms級
可用性：高，基於主從架構實現高可用性
訊息可靠性：有較低的概率丟失資料
功能支援：MQ領域的功能極其完備
缺點:
官方社群現在對ActiveMQ 5.x維護越來越少，較少在大規模吞吐的場景中使用。
- Kafka
號稱大資料的殺手鐗，談到大資料領域內的訊息傳輸，則繞不開Kafka，這款為大資料而生的訊息中介軟體，以其百萬級TPS的吞吐量名聲大噪，迅速成為大資料領域的寵兒，在資料採集、傳輸、儲存的過程中發揮著舉足輕重的作用。
Apache Kafka它最初由LinkedIn公司基於獨特的設計實現為一個分散式的提交日誌系統( a distributed commit log)，之後成為Apache專案的一部分。
目前已經被LinkedIn，Uber, Twitter, Netflix等大公司所採納。
優點
效能卓越，單機寫入TPS約在百萬條/秒，最大的優點，就是吞吐量高。
時效性：ms級
可用性：非常高，kafka是分散式的，一個數據多個副本，少數機器宕機，不會丟失資料，不會導致不可用
消費者採用Pull方式獲取訊息, 訊息有序, 通過控制能夠保證所有訊息被消費且僅被消費一次;
有優秀的第三方Kafka Web管理介面Kafka-Manager；
在日誌領域比較成熟，被多家公司和多個開源專案使用；
功能支援：功能較為簡單，主要支援簡單的MQ功能，在大資料領域的實時計算以及日誌採集被大規模使用
缺點：
Kafka單機超過64個佇列/分割槽，Load會發生明顯的飆高現象，佇列越多，load越高，傳送訊息響應時間變長
使用短輪詢方式，實時性取決於輪詢間隔時間；
消費失敗不支援重試；
支援訊息順序，但是一臺代理宕機後，就會產生訊息亂序；
社群更新較慢；
- RabbitMQ
RabbitMQ 2007年釋出，是一個在AMQP(高階訊息佇列協議)基礎上完成的，可複用的企業訊息系統，是當前最主流的訊息中介軟體之一。
RabbitMQ優點：
由於erlang語言的特性，mq 效能較好，高併發；
吞吐量到萬級，MQ功能比較完備
健壯、穩定、易用、跨平臺、支援多種語言、文件齊全；
開源提供的管理介面非常棒，用起來很好用
社群活躍度高；
RabbitMQ缺點：
erlang開發，很難去看懂原始碼，基本職能依賴於開源社群的快速維護和修復bug，不利於做二次開發和維護。
RabbitMQ確實吞吐量會低一些，這是因為他做的實現機制比較重。
需要學習比較複雜的介面和協議，學習和維護成本較高。
- RocketMQ
RocketMQ出自 阿里公司的開源產品，用 Java 語言實現，在設計時參考了 Kafka，並做出了自己的一些改進。
RocketMQ在阿里集團被廣泛應用在訂單，交易，充值，流計算，訊息推送，日誌流式處理，binglog分發等場景。
RocketMQ優點：
單機吞吐量：十萬級
可用性：非常高，分散式架構
訊息可靠性：經過引數優化配置，訊息可以做到0丟失
功能支援：MQ功能較為完善，還是分散式的，擴充套件性好
支援10億級別的訊息堆積，不會因為堆積導致效能下降
原始碼是java，我們可以自己閱讀原始碼，定製自己公司的MQ，可以掌控
RocketMQ缺點：
支援的客戶端語言不多，目前是java及c++，其中c++不成熟；
社群活躍度一般
沒有在 mq 核心中去實現JMS等介面，有些系統要遷移需要修改大量程式碼