各大主流消息中間件有哪些區別

本篇內容主要講解“各大主流消息中間件有哪些區別”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“各大主流消息中間件有哪些區別”吧!

目錄  

前言

1. 主流消息中間件介紹——ActiveMQ    

1.1 特點      

1.2 架構模式      

1.3 小結      

2. 主流消息中間件介紹——Kafka    

2.1 特點      

2.2 架構模式      

2.3 小結      

3. 主流消息中間件介紹——RocketMQ    

3.1 特點      

3.2 架構模式      

3.3 小結      

4. 為什么選擇RabbitMQ？

5. 主流消息中間件介紹——RabbitMQ    

5.1 特點      

6. 對比分析圖      

前言

消息隊列已經逐漸成為企業IT系統內部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成為異步RPC的主要手段之一。當今市面上有很多主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，炙手可熱的Kafka，阿里巴巴自主開發RocketMQ等。今天主要來介紹了下幾大主流消息中間件的區別與聯系。

1. 主流消息中間件介紹——ActiveMQ

ActiveMQ是由Apache出品，ActiveMQ是一個完全支持JMS1.1和J2EE 1.4規范的JMS Provider實現。它非常快速，支持多種語言的客戶端和協議，而且可以非常容易的嵌入到企業的應用環境中，并有許多高級功能。

1.1 特點

• ActiveMQ是Apache出品，最流行的，能力強勁的開源消息總線，并且它是一個完全支持JMS規范的消息中間件

• 其豐富的API、多種集群構建模式使得他成為業界老牌消息中間件，在中小型企業中應用廣泛!

• MQ衡量指標：服務性能、數據存儲、集群架構。

ActiveMQ現在用的比較少，因為ActiveMQ相比其他的MQ的性能來說比較一般。現如今高并發、大數據的應用場景隨處可見。如果這時候在MQ的選擇上，那么ActiveMQ就顯得力不從心了。

衡量一個MQ的指標，主要有三個方面：服務性能、數據存儲、集群架構
服務性能：ActiveMQ的性能不是特別好，面對超大規模并發時候，總是會出現各種各樣的小問題，比如阻塞，消息堆積過多，產生一些延遲等等一些問題。
數據存儲：ActiveMQ默認采用KahaDB內存存儲方式。也可以采用一些高性能的存儲方式，比如：google的LevelDb 基于內c存的。如果是為了保證消息的可靠，也可以采用mysql或者oracle數據庫。
集群架構：ActiveMQ流行那么多年，與其他組件集成的Api也是十分完善的。如果不是特別大的并發場景下，ActiveMQ也是一個不錯的選擇。因為ActiveMQ的集群架構模式也是十分好。

1.2 架構模式

Masrer-Slave模式
主備模式，利用Zookeeper進行兩個或多個節點的協調。其中的主節點是對外提供服務的，而另外的從節點啟動著，但是不對外提供服務。當主節點掛掉，利用Zookeeper進行一個高可用的切換，將Salve節點切換成主節點，繼續對外提供服務。

NetWork模式

本質是兩組主備模式的集成，中間用NewWork網關，做一個連接配置，就可以實現分布式集群。

1.3 小結

優點：

• 跨平臺(JAVA編寫與平臺無關，ActiveMQ幾乎可以運行在任何的JVM上)

• 可以用JDBC：可以將數據持久化到數據庫。雖然使用JDBC會降低ActiveMQ的性能，但是數據庫一直都是開發人員最熟悉的存儲介質

• 支持JMS規范：支持JMS規范提供的統一接口

• 支持自動重連和錯誤重試機制

• 有安全機制：支持基于shiro，jaas等多種安全配置機制，可以對Queue/Topic進行認證和授權

• 監控完善：擁有完善的監控，包括WebConsole，JMX，Shell命令行，Jolokia的RESTful API

• 界面友善：提供的WebConsole可以滿足大部分情況，還有很多第三方的組件可以使用，比如hawtio

缺點：

• 社區活躍度不及RabbitMQ高

• 根據其他用戶反饋，會出莫名其妙的問題，會丟失消息

• 目前重心放到activemq6.0產品Apollo，對5.x的維護較少

• 不適合用于上千個隊列的應用場景

2. 主流消息中間件介紹——Kafka

Apache Kafka是一個分布式消息發布訂閱系統。它最初由LinkedIn公司基于獨特的設計實現為一個分布式的日志提交系統(a distributed commit log)，之后成為Apache項目的一部分。Kafka性能高效、可擴展良好并且可持久化。它的分區特性，可復制和可容錯都是其不錯的特性。

2.1 特點

kafka是LinkedIn開源的分布式發布-定于消息系統，目前歸屬于Apache頂級項目。Kafka主要特點是給予Pull的模式來處理消費消息，追求高吞吐量，一開始的目的就是用于日志收集和傳輸。0.8版本開始支持復制，不支持事務，對消息的重復、丟失、錯誤沒有嚴格要求，適合產生大量數據的互聯網服務的數據收集業務。這里可以看出kafka只關注吞吐量。因此，在使用kafka的時候，注意業務是否允許消息重復、丟失、錯誤等。如果允許的話，kafka是最合適的。因為它的性能是最高的。即使在廉價的服務器上，也能支持單機每秒100k條以上的數據量。所以說它的性能是非常好的。kafka僅僅使用內存進行存儲，只要有足夠的內存，就能夠足夠大的吞吐量。因為kafka并沒有在磁盤上進行讀寫。

• 快速持久化：可以在O(1)的系統開銷下進行消息持久化；

• 高吞吐：在一臺普通的服務器上既可以達到10W/s的吞吐速率；

• 完全的分布式系統：Broker、Producer和Consumer都原生自動支持分布式，自動實現負載均衡；

• 支持同步和異步復制兩種高可用機制；

• 支持數據批量發送和拉取；

• 零拷貝技術(zero-copy)：減少IO操作步驟，提高系統吞吐量；

• 數據遷移、擴容對用戶透明；

• 無需停機即可擴展機器；

• 其他特性：豐富的消息拉取模型、高效訂閱者水平擴展、實時的消息訂閱、億級的消息堆積能力、定期刪除機制

2.2 架構模式

kafka架構模式

主要依賴Zookeeper進行協調管理，每一個kafka可以進行副本復制，也就是數據同步。假如說：有一條數據落在第一個節點上，那么就會進行repilicate 復制，這樣在運行中每個節點就有一份數據，一共就有三分數據。如果說其中一臺宕機，也能從另外兩個節點中獲取數據。部署方案建議：跨機房部署。即使有一臺機子宕機，在數據上也是沒有問題的。如果在整個地點宕機了。那么我們的數據也就丟失了。這也是大公司需要考慮的異地災備。當然kafka主要關注性能的，對于數據的可靠性關注并高。

2.3 小結

優點：

• 客戶端語言豐富：支持Java、.Net、PHP、Ruby、Python、Go等多種語言；

• 高性能：單機寫入TPS約在100萬條/秒，消息大小10個字節；

• 提供完全分布式架構，并有replica機制，擁有較高的可用性和可靠性，理論上支持消息無限堆積；

• 支持批量操作；

• 消費者采用Pull方式獲取消息。消息有序，通過控制能夠保證所有消息被消費且僅被消費一次；

• 有優秀的第三方KafkaWeb管理界面Kafka-Manager；

• 在日志領域比較成熟，被多家公司和多個開源項目使用。

缺點：

• Kafka單機超過64個隊列/分區時，Load時會發生明顯的飆高現象。隊列越多，負載越高，發送消息響應時間變長；

• 使用短輪詢方式，實時性取決于輪詢間隔時間；

• 消費失敗不支持重試；

• 支持消息順序，但是一臺代理宕機后，就會產生消息亂序；

• 社區更新較慢。

3. 主流消息中間件介紹——RocketMQ

RocketMQ是阿里開源的消息中間件，目前也已經孵化為Apache頂級項目。用Java語言實現，在設計時參考了Kafka，并做出了自己的一些改進，消息可靠性上比Kafka更好。RocketMQ在阿里內部被廣泛應用在訂單，交易，充值，流計算，消息推送，日志流式處理，binglog分發等場景。

3.1 特點

核心的特點如下：

• 保證消息的順序性，消息按順序消費。

• 提供了豐富的拉取和處理模式。

• 高效的訂閱者，也可以進行水平擴展。

• 承載上億級別的消息堆積能力。

3.2 架構模式

RocketMQ集群架構模式
1.Master-Slave（主從）模式
2.雙Master模式。
3.雙主雙從模式。
4.多主多從模式。
5.一主多從模式。
可選方案許多種可供選擇。

等等，參考了許多開源的設方式。

集群拓撲

阿里覺得Zookeeper性能太低，自己搭建了NameServer，這個NameServer代碼也十分精簡，一共也就幾百行代碼。有興趣可以去讀源碼。

3.3 小結

優點：

• 單機支持1萬以上持久化隊列；

• RocketMQ的所有消息都是持久化的，先寫入系統PAGECACHE，然后刷盤，可以保證內存與磁盤都有一份數據，而訪問時，直接從內存讀取。

• 模型簡單，接口易用（JMS的接口很多場合并不太實用）；

• 性能非常好，可以允許大量堆積消息在Broker中；

• 支持多種消費模式，包括集群消費、廣播消費等；

• 各個環節分布式擴展設計，支持主從和高可用；

• 開發度較活躍，版本更新很快。

缺點：

• 支持的 客戶端語言不多，目前是Java及C++，其中C++還不成熟

• 維護RocketMQ需要專業的團隊

• 商業版收費，有許多功能是不對外提供的。

• 沒有在MQ核心里實現JMS等接口

4. 為什么選擇RabbitMQ？

1.ActiveMQ，性能不是很好，因此在高并發的場景下，直接被pass掉了。它的Api很完善，在中小型互聯網公司可以去使用。
2.kafka，主要強調高性能，如果對業務需要可靠性消息的投遞的時候。那么就不能夠選擇kafka了。但是如果做一些日志收集呢，kafka還是很好的。因為kafka的性能是十分好的。
3.RocketMQ，它的特點非常好。它高性能、滿足可靠性、分布式事物、支持水平擴展、上億級別的消息堆積、主從之間的切換等等。MQ的所有優點它基本都滿足。但是它最大的缺點：商業版收費。因此它有許多功能是不對外提供的。

那么說完這三種MQ還有沒有其他MQ能夠選擇呢？有的，也是這次學習的MQ——RabbitMQ。

5. 主流消息中間件介紹——RabbitMQ

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

5.1 特點

RabbitMQ是使用Erlang語言開發的開源消息隊列系統，基于AMQP協議來實現。
AMQP的主要特征是面向消息、隊列、路由（包括點對點和發布/訂閱）、可靠性、安全。
AMQP協議更多用在企業系統內，對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。
RabbitMQ的可靠性是非常好的，數據能夠保證百分之百的不丟失。可以使用鏡像隊列，它的穩定性非常好。所以說在我們互聯網的金融行業。對數據的穩定性和可靠性要求都非常高的情況下，我們都會選擇RabbitMQ。當然沒有kafka性能好，但是要比AvtiveMQ性能要好很多。也可以自己做一些性能的優化。
RabbitMQ可以構建異地雙活架構，包括每一個節點存儲方式可以采用磁盤或者內存的方式。

RabbitMQ的集群架構

圖中說的就是，我們可以采用三個節點作為RabbitMQ的一組集群，當然可以有許多組。節點與節點之間采用mirror queue。基于這種方式，能夠保證數據百分之百的不丟失。
前端可以去做負載均衡，比如負載均衡組件：HA-proxy ，進行TCP級別的負載。
如果想做一個高可用的話，就需要借助keepAlived做一個高可用的配置。
比如前端加一個虛擬的VIP，通過VIP路由到指定的負載均衡組件，再有它路由到RabbtMQ的某一個節點。
這就是整個RabbitMQ集群架構。
能夠實現非常完善，高可用并且性能也十分好，穩定性超強。并且有各種集群恢復手段。
比如:某一個節點掛了，或者某個磁盤損壞了，它也能進行一個消息修復。基于這么多優點，我們一定要把RabbitMQ學好。

6. 對比分析圖

到此，相信大家對“各大主流消息中間件有哪些區別”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！