常用消息中间件选择
給大家推薦一款好用的CSDN云服務，新人首購折扣哦，點擊下圖跳轉：
文章目錄
- 一、ActiveMQ
- 二、RabbitMQ
- 三、RocketMQ
- 四、Kafka
- 五、ZeroMQ
- 六、主要消息中間件的比較
有哪些主流的消息中間件？
當前業(yè)界比較流行的開源消息中間件包括：ActiveMQ、RabbitMQ、RocketMQ、Kafka、ZeroMQ等。
其中應用最為廣泛的要數(shù)RabbitMQ、RocketMQ、Kafka 這三款。
Redis在某種程度上也可以是實現(xiàn)類似 “Queue” 和“ Pub/Sub” 的機制，嚴格意義上不算消息中間件。
一般的業(yè)務系統(tǒng)要引入 MQ，最早大家都用 ActiveMQ，但是現(xiàn)在確實大家用的不多了，沒經(jīng)過大規(guī)模吞吐量場景的驗證，社區(qū)也不是很活躍，所以大家還是算了吧，不推薦用這個了。
后來大家開始用 RabbitMQ，但是確實 erlang 語言阻止了大量的 Java 工程師去深入研究和掌控它，對公司而言，幾乎處于不可控的狀態(tài)，但是確實人家是開源的，比較穩(wěn)定的支持，活躍度也高。
不過現(xiàn)在確實越來越多的公司，會去用 RocketMQ，確實很不錯（阿里出品），但社區(qū)可能有突然黃掉的風險，對自己公司技術實力有絕對自信的，推薦用 RocketMQ，否則回去老老實實用 RabbitMQ 吧，人家有活躍的開源社區(qū)，絕對不會黃。
所以中小型公司，技術實力較為一般，技術挑戰(zhàn)不是特別高，用 RabbitMQ 是不錯的選擇；大型公司，基礎架構研發(fā)實力較強，用 RocketMQ 是很好的選擇。
如果是大數(shù)據(jù)領域的實時計算、日志采集等場景，用 Kafka 是業(yè)內標準的，絕對沒問題，社區(qū)活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規(guī)范。
一、ActiveMQ
Apache下的一個子項目。使用Java完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實現(xiàn)，少量代碼就可以高效地實現(xiàn)高級應用場景?？刹灏蔚膫鬏攨f(xié)議支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。
ActiveMQ、RabbitMQ、ZeroMQ均支持常用的多種語言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。
ActiveMQ只需要操作系統(tǒng)支持Java虛擬機，便可執(zhí)行。
ActiveMQ可以很容易內嵌到使用Spring的系統(tǒng)里面去通過了常見J2EE服務器的測試。
JMS即Java消息服務（Java Message Service）應用程序接口，是一個Java平臺中關于面向消息中間件（MOM）的API，用于在兩個應用程序之間，或分布式系統(tǒng)中發(fā)送消息，進行異步通信。其豐富的 API 、多種集群構建模式使得他成為業(yè)界老牌消息中間件，在中小型企業(yè)中應用廣泛！
優(yōu)點：
- ActiveMQ采用消息推送方式，所以最適合的場景是默認消息都可在短時間內被消費。數(shù)據(jù)量越大，查找和消費消息就越慢，消息積壓程度與消息速度成反比。
- 單機吞吐量萬級，時效性 ms 級，可用性高，基于主從架構實現(xiàn)高可用性，消息可靠性：有較低的概率丟失數(shù)據(jù)。
缺點：
- 吞吐量低。由于 ActiveMQ 需要建立索引，導致吞吐量下降。這是無法克服的缺點，只要使用完全符合 JMS 規(guī)范的消息中間件，就要接受這個級別的TPS。
- 無分片功能。這是一個功能缺失，JMS 并沒有規(guī)定消息中間件的集群、分片機制。而由于 ActiveMQ 是偉企業(yè)級開發(fā)設計的消息中間件，初衷并不是為了處理海量消息和高并發(fā)請求。如果一臺服務器不能承受更多消息，則需要橫向拆分。ActiveMQ 官方不提供分片機制，需要自己實現(xiàn)。
- 官方社區(qū)現(xiàn)在對 ActiveMQ 5.x 維護越來越少，高吞吐量場景較少使用。
二、RabbitMQ
使用Erlang編寫的一個開源的消息隊列，本身支持很多的協(xié)議：AMQP，XMPP，SMTP，STOMP，也正是如此，使的它變的非常重量級，更適合于企業(yè)級的開發(fā)。同時實現(xiàn)了Broker架構，核心思想是生產(chǎn)者不會將消息直接發(fā)送給隊列，消息在發(fā)送給客戶端時先在中心隊列排隊。對路由(Routing)，負載均衡(Load balance)、數(shù)據(jù)持久化都有很好的支持。多用于進行企業(yè)級的ESB整合。
RabbitMQ 開始是用在電信業(yè)務的可靠通信的，也是少有的幾款支持AMQP協(xié)議的產(chǎn)品之一。
優(yōu)點：
缺點：
三、RocketMQ
阿里系下開源的一款分布式、隊列模型的消息中間件，原名Metaq，3.0版本名稱改為RocketMQ，是阿里參照kafka設計思想使用java實現(xiàn)的一套mq。同時將阿里系內部多款mq產(chǎn)品（Notify、metaq）進行整合，只維護核心功能，去除了所有其他運行時依賴，保證核心功能最簡化，在此基礎上配合阿里上述其他開源產(chǎn)品實現(xiàn)不同場景下mq的架構，被阿里巴巴廣泛應用在訂單，交易，充值，流計算，消息推送，日志流式處理，binglog 分發(fā)等場景。
具有以下特點：
- 能夠保證嚴格的消息順序
- 提供針對消息的過濾功能
- 提供豐富的消息拉取模式
- 高效的訂閱者水平擴展能力
- 實時的消息訂閱機制
- 億級消息堆積能力
官方提供了一些不同于kafka的對比差異：
https://rocketmq.apache.org/docs/motivation/
優(yōu)點：
缺點：
四、Kafka
大數(shù)據(jù)的殺手锏，談到大數(shù)據(jù)領域內的消息傳輸，則繞不開 Kafka，這款為大數(shù)據(jù)而生的消息中間件，以其百萬級 TPS 的吞吐量名聲大噪，迅速成為大數(shù)據(jù)領域的寵兒，在數(shù)據(jù)采集、傳輸、存儲的過程中發(fā)揮著舉足輕重的作用。目前已經(jīng)被 LinkedIn，Uber, Twitter, Netflix 等大公司所采納。
Apache下的一個子項目，使用scala和java實現(xiàn)的一個高性能分布式Pub/Sub消息隊列系統(tǒng)，具有以下特性：
- 快速持久化：通過磁盤順序讀寫與零拷貝機制，可以在O(1)的系統(tǒng)開銷下進行消息持久化；
- 高吞吐：在一臺普通的服務器上既可以達到10W/s的吞吐速率；
- 高堆積：支持topic下消費者較長時間離線，消息堆積量大；
- 完全的分布式系統(tǒng)：Broker、Producer、Consumer都原生自動支持分布式，依賴zookeeper自動實現(xiàn)復雜均衡；
- 支持Hadoop數(shù)據(jù)并行加載：對于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實時處理的限制，這是一個可行的解決方案。
Kafka的可靠性，穩(wěn)定性和功能特性基本滿足大多數(shù)的應用場景。跟周邊系統(tǒng)的兼容性是數(shù)一數(shù)二的，尤其是大數(shù)據(jù)和流計算領域，幾乎所有相關的開源軟件都支持Kafka。Kafka是Scala和Java開發(fā)的，對批處理和異步處理做了大量的設計，因此Kafka可以得到非常高的性能。它的異步消息的發(fā)送和接收是最好的，但是跟RocketMQ拉不開數(shù)量級，每秒處理幾十萬的消息。如果是異步消息，并且開啟了壓縮，Kafka最終可以達到每秒處理2000w消息的級別。
優(yōu)點：
缺點：
五、ZeroMQ
號稱最快的消息隊列系統(tǒng)，專門為高吞吐量/低延遲的場景開發(fā)，在金融界的應用中經(jīng)常使用，偏重于實時數(shù)據(jù)通信場景。ZMQ能夠實現(xiàn)RabbitMQ不擅長的高級/復雜的隊列，但是開發(fā)人員需要自己組合多種技術框架，開發(fā)成本高。因此ZeroMQ具有一個獨特的非中間件的模式，更像一個socket library，你不需要安裝和運行一個消息服務器或中間件，因為你的應用程序本身就是使用ZeroMQ API完成邏輯服務的角色。但是ZeroMQ僅提供非持久性的隊列，如果down機，數(shù)據(jù)將會丟失。如：Twitter的Storm中使用ZeroMQ作為數(shù)據(jù)流的傳輸。
ZeroMQ套接字是與傳輸層無關的：ZeroMQ套接字對所有傳輸層協(xié)議定義了統(tǒng)一的API接口。默認支持 進程內(inproc) ，進程間(IPC) ，多播，TCP協(xié)議，在不同的協(xié)議之間切換只要簡單的改變連接字符串的前綴?？梢栽谌魏螘r候以最小的代價從進程間的本地通信切換到分布式下的TCP通信。ZeroMQ在背后處理連接建立，斷開和重連邏輯。
特性：
- 無鎖的隊列模型：對于跨線程間的交互（用戶端和session）之間的數(shù)據(jù)交換通道pipe，采用無鎖的隊列算法CAS；在pipe的兩端注冊有異步事件，在讀或者寫消息到pipe的時，會自動觸發(fā)讀寫事件。
- 批量處理的算法：對于批量的消息，進行了適應性的優(yōu)化，可以批量的接收和發(fā)送消息。
- 多核下的線程綁定，無須CPU切換：區(qū)別于傳統(tǒng)的多線程并發(fā)模式，信號量或者臨界區(qū)，zeroMQ充分利用多核的優(yōu)勢，每個核綁定運行一個工作者線程，避免多線程之間的CPU切換開銷。
六、主要消息中間件的比較
Kafka：Kafka 主要特點是基于Pull 的模式來處理消息消費，追求高吞吐量，一開始的目的就是用于日志收集和傳輸，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務的數(shù)據(jù)收集業(yè)務。大型公司建議可以選用，如果有日志采集功能，肯定是首選 kafka 了。
RocketMQ：天生為金融互聯(lián)網(wǎng)領域而生，對于可靠性要求很高的場景，尤其是電商里面的訂單扣款，以及業(yè)務削峰，在大量交易涌入時，后端可能無法及時處理的情況。RoketMQ 在穩(wěn)定性上可能更值得信賴，這些業(yè)務場景在阿里雙 11 已經(jīng)經(jīng)歷了多次考驗，如果你的業(yè)務有上述并發(fā)場景，建議可以選擇 RocketMQ。
RabbitMQ：結合 erlang 語言本身的并發(fā)優(yōu)勢，性能好時效性微秒級，社區(qū)活躍度也比較高，管理界面用起來十分方便，如果你的數(shù)據(jù)量沒有那么大，中小型公司優(yōu)先選擇功能比較完備的 RabbitMQ。
兩個表格：
總結
- 上一篇： 告诉你C盘里的每个文件夹都是干什么用的.
- 下一篇： 2016年07月