什么是消息？

“消息”是在兩臺計算機間傳送的數據單位。

消息可以非常簡單，例如只包含文本字符串；也可以更復雜，可能包含嵌入對象。

什么是隊列？

隊列(Queue)隊列是一種先進先出(FIFO)的數據結構。

什么是消息隊列？

消息隊列是一個存放消息的容器，消息隊列是分布式系統中重要的組件，使用消息隊列主要是為了通過異步處理提高系統性能、削峰、降低系統耦合性。

兩種基本的消息模型是什么？

1. 點到點(P2P)模型

使用隊列(Queue)作為消息通信載體；滿足生產者與消費者模式，一條消息只能被一個消費者使用，未被消費的消息在隊列中保留直到被消費或超時。

比如：我們生產者發送100條消息的話，兩個消費者來消費一般情況下兩個消費者會按照消息發送的順序各自消費一半。

2. 發布/訂閱(Pub/Sub)模型

發布訂閱模型(Pub/Sub)使用主題(Topic)作為消息通信載體，類似于廣播模式。

發布者發布一條消息以后，該消息通過主題傳遞給所有的訂閱者。在一條消息廣播之后再訂閱的用戶則是收不到該條消息的。

什么是JMS ？

JMS(JAVA Message Service，Java消息服務)是java的消息服務，JMS的客戶端之間可以通過JMS服務進行異步的消息傳輸。

JMS API是一個消息服務的標準或者說是規范，允許應用程序組件基于JavaEE平臺創建、發送、接收和讀取消息。它使分布式通信耦合度更低，消息服務更加可靠以及異步性。

ActiveMQ 就是基于 JMS 規范實現的。

JMS提供了兩種消息模型：

①Peer-2-Peer

②Pub/sub

什么是 AMQP ？

AMQP，即Advanced Message Queuing Protocol，一個提供統一消息服務的應用層標準高級消息隊列協議(二進制應用層協議)，是應用層協議的一個開放標準,為面向消息的中間件設計，兼容 JMS。基于此協議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件同產品，不同的開發語言等條件的限制。

AMQP RabbitMQ 就是基于 AMQP 協議實現的。

提供了五種消息模型：

①direct exchange；

②fanout exchange；

③topic change；

④headers exchange；

⑤system exchange。

本質來講，后四種和JMS的pub/sub模型沒有太大差別，僅是在路由機制上做了更詳細的劃分。

AMQP 為消息定義了線路層(wire-level protocol)的協議，而JMS所定義的是API規范。在 Java 體系中，多個client均可以通過JMS進行交互，不需要應用修改代碼，但是其對跨平臺的支持較差。而AMQP天然具有跨平臺、跨語言特性。

JMS 支持TextMessage、MapMessage 等復雜的消息類型；而 AMQP 僅支持 byte[] 消息類型(復雜的類型可序列化后發送)。

由于Exchange 提供的路由算法，AMQP可以提供多樣化的路由方式來傳遞消息到消息隊列，而 JMS 僅支持隊列和主題/訂閱方式兩種。

什么是中間件？

中間件是一種獨立的系統軟件或服務程序，分布式應用軟件借助這種軟件在不同的技術之間共享資源。

中間件位于客戶機/服務器的操作系統之上，管理計算機資源和網絡通訊非底層操作系統軟件，非業務應用軟件，不是直接給最終用戶使用的，不能直接給客戶帶來價值的軟件統稱中間件。

中間件是指網絡環境下處于操作系統、數據庫等系統軟件和應用軟件之間的一種起連接作用的分布式軟件，主要解決異構網絡環境下分布式應用軟件的互連與互操作問題，提供標準接口、協議，屏蔽實現細節，提高應用系統易移植性。

什么是消息中間件？

消息隊列中間件(簡稱消息中間件)是利用高效可靠的消息傳遞機制，進行異步的數據傳輸，并基于數據通信進行分布式系統的集成。

通過提供消息隊列模型和消息傳遞機制，消息中間件可以在分布式環境下擴展進程間的通信，它可以在分布式環境下提供應用解耦、彈性伸縮、冗余存儲、流量削峰、異步通信、數據同步等等功能。

消息中間件作為分布式系統架構中的一個重要組件，有著舉足輕重的地位。

消息中間件有哪些組成部分？

1 Broker

消息服務器，作為server提供消息核心服務。

2 Producer

消息生產者，業務的發起方，負責生產消息傳輸給broker。

3 Consumer

消息消費者，業務的處理方，負責從broker獲取消息并進行業務邏輯處理。

4 Topic

主題，發布訂閱模式下的消息統一匯集地，不同生產者向topic發送消息，由MQ服務器分發到不同的訂閱者，實現消息的廣播。

5 Queue

隊列，PTP模式下，特定生產者向特定queue發送消息，消費者訂閱特定的queue完成指定消息的接收。

6 Message

消息體，根據不同通信協議定義的固定格式進行編碼的數據包，來封裝業務數據，實現消息的傳輸。

消息中間件的使用場景有哪些？

1 異步通信

有些業務不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然后在需要的時候再去處理它們。

2 解耦

降低工程間的強依賴程度，針對異構系統進行適配。在項目啟動之初來預測將來項目會碰到什么需求，是極其困難的。通過消息系統在處理過程中間插入了一個隱含的、基于數據的接口層，兩邊的處理過程都要實現這一接口，當應用發生變化時，可以獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。

3 冗余

有些情況下，處理數據的過程會失敗。除非數據被持久化，否則將造成丟失。消息隊列把數據進行持久化直到它們已經被完全處理，通過這一方式規避了數據丟失風險。許多消息隊列所采用的”插入-獲取-刪除”范式中，在把一個消息從隊列中刪除之前，需要你的處理系統明確的指出該消息已經被處理完畢，從而確保你的數據被安全的保存直到你使用完畢。

4 擴展性

因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調節參數。便于分布式擴容。

5 過載保護

在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量無法提取預知；如果以為了能處理這類瞬間峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列能夠使關鍵組件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全崩潰。

6 可恢復性

系統的一部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復后被處理。

7 順序保證

在大多使用場景下，數據處理的順序都很重要。大部分消息隊列本來就是排序的，并且能保證數據會按照特定的順序來處理。

8 緩沖

在任何重要的系統中，都會有需要不同的處理時間的元素。消息隊列通過一個緩沖層來幫助任務最高效率的執行，該緩沖有助于控制和優化數據流經過系統的速度。以調節系統響應時間。

9 數據流處理

分布式系統產生的海量數據流，如：業務日志、監控數據、用戶行為等，針對這些數據流進行實時或批量采集匯總，然后進行大數據分析是當前互聯網的必備技術，通過消息隊列完成此類數據收集是最好的選擇。

引入消息中間件有什么優勢？

1. 通過異步處理提高系統性能(削峰、減少響應所需時間)

2. 降低系統耦合性

引入消息中間件有什么劣勢？

1. 系統可用性降低：系統可用性在某種程度上降低，比如要考慮消息丟失、消息中間件宕機等問題。

2. 系統復雜性提高：加入MQ之后，你需要保證消息沒有被重復消費、處理消息丟失的情況、保證消息傳遞的順序性，等等。

3. 一致性問題：消息隊列可以實現異步，消息隊列帶來的異步確實可以提高系統響應速度，但消費者沒有正確消費可能會引入一致性問題。

有哪些常用的消息中間件？

市面上有很多消息中間件產品，你也可以基于開源中間件產品進行二次開發，或者使用文件系統、Redis等自己實現一個簡單的消息中間件功能。

下面我們介紹幾個常用的消息中間件及其對比。

特性	ActiveMQ	RabbitMQ	RocketMQ	kafka
開發語言	java	erlang	java	scala
單機吞吐量	萬級	萬級	10萬級	10萬級
時效性	ms級	us級	ms級	ms級以上
可用性	高(主從架構)	高(主從架構)	非常高(分布式架構)	非常高(分布式架構)
功能特性	成熟的產品，在很多公司得到應用；有較多的文檔；各種協議支持較好	基于erlang開發，所以并發能力很強，性能極其好，延時很低；管理界面較豐富	MQ功能比較完備，擴展性佳	只支持主要的MQ功能，像一般消息查詢，消息回溯等功能沒有提供；畢竟是為大數據準備的，在大數據領域應用廣

消息中間件技術選型要考慮哪些東西？

1. 功能維度

1.1 優先級隊列

優先級隊列不同于先進先出隊列，優先級高的消息具備優先被消費的特權，這樣可以為下游提供不同消息級別的保證。

不過這個優先級也是需要有一個前提的：如果消費者的消費速度大于生產者的速度，并且消息中間件服務器(一般簡單的稱之為Broker)中沒有消息堆積，那么對于發送的消息設置優先級也就沒有什么實質性的意義了，因為生產者剛發送完一條消息就被消費者消費了，那么就相當于Broker中至多只有一條消息，對于單條消息來說優先級是沒有什么意義的。

1.2 延遲隊列

延遲隊列存儲的是對應的延遲消息，所謂“延遲消息”是指當消息被發送以后，并不想讓消費者立刻拿到消息，而是等待特定時間后，消費者才能拿到這個消息進行消費。

延遲隊列一般分為兩種：基于消息的延遲和基于隊列的延遲。

基于消息的延遲是指為每條消息設置不同的延遲時間，那么每當隊列中有新消息進入的時候就會重新根據延遲時間排序，當然這也會對性能造成極大的影響。

實際應用中大多采用基于隊列的延遲，設置不同延遲級別的隊列，比如5s、10s、30s、1min、5mins、10mins等，每個隊列中消息的延遲時間都是相同的，這樣免去了延遲排序所要承受的性能之苦，通過一定的掃描策略(比如定時)即可投遞超時的消息。

1.3 死信隊列

由于某些原因消息無法被正確的投遞，為了確保消息不會被無故的丟棄，一般將其置于一個特殊角色的隊列，這個隊列一般稱之為死信隊列。

與此對應的還有一個“回退隊列”的概念，試想如果消費者在消費時發生了異常，那么就不會對這一次消費進行確認(Ack)，進而發生回滾消息的操作之后消息始終會放在隊列的頂部，然后不斷被處理和回滾，導致隊列陷入死循環。

為了解決這個問題，可以為每個隊列設置一個回退隊列，它和死信隊列都是為異常的處理提供的一種機制保障。實際情況下，回退隊列的角色可以由死信隊列和重試隊列來扮演。

1.4 重試隊列

重試隊列其實可以看成是一種回退隊列，具體指消費端消費消息失敗時，為防止消息無故丟失而重新將消息回滾到Broker中。

與回退隊列不同的是重試隊列一般分成多個重試等級，每個重試等級一般也會設置重新投遞延時，重試次數越多投遞延時就越大。

舉個例子：消息第一次消費失敗入重試隊列Q1，Q1的重新投遞延遲為5s，在5s過后重新投遞該消息；如果消息再次消費失敗則入重試隊列Q2，Q2的重新投遞延遲為10s，在10s過后再次投遞該消息。以此類推，重試越多次重新投遞的時間就越久，為此需要設置一個上限，超過投遞次數就入死信隊列。

重試隊列與延遲隊列有相同的地方，都是需要設置延遲級別，它們彼此的區別是：延遲隊列動作由內部觸發，重試隊列動作由外部消費端觸發；延遲隊列作用一次，而重試隊列的作用范圍會向后傳遞。

1.5 消費模式

消費模式分為推(push)模式和拉(pull)模式。

推模式是指由Broker主動推送消息至消費端，實時性較好，不過需要一定的流制機制來確保服務端推送過來的消息不會壓垮消費端。

而拉模式是指消費端主動向Broker端請求拉取(一般是定時或者定量)消息，實時性較推模式差，但是可以根據自身的處理能力而控制拉取的消息量。

1.6 廣播消費

消息一般有兩種傳遞模式：點對點(P2P，Point-to-Point)模式和發布/訂閱(Pub/Sub)模式。

對于點對點的模式而言，消息被消費以后，隊列中不會再存儲，所以消息消費者不可能消費到已經被消費的消息。雖然隊列可以支持多個消費者，但是一條消息只會被一個消費者消費。

發布訂閱模式定義了如何向一個內容節點發布和訂閱消息，這個內容節點稱為主題(topic)，主題可以認為是消息傳遞的中介，消息發布者將消息發布到某個主題，而消息訂閱者則從主題中訂閱消息。主題使得消息的訂閱者與消息的發布者互相保持獨立，不需要進行接觸即可保證消息的傳遞，發布/訂閱模式在消息的一對多廣播時采用。

1.7 消息回溯

一般消息在消費完成之后就被處理了，之后再也不能消費到該條消息。

消息回溯正好相反，是指消息在消費完成之后，還能消費到之前被消費掉的消息。

對于消息而言，經常面臨的問題是“消息丟失”，至于是真正由于消息中間件的缺陷丟失還是由于使用方的誤用而丟失一般很難追查，如果消息中間件本身具備消息回溯功能的話，可以通過回溯消費復現“丟失的”消息進而查出問題的源頭之所在。消息回溯的作用遠不止與此，比如還有索引恢復、本地緩存重建，有些業務補償方案也可以采用回溯的方式來實現。

1.8 消息堆積與持久化

流量削峰是消息中間件的一個非常重要的功能，而這個功能其實得益于其消息堆積能力。

從某種意義上來講，如果一個消息中間件不具備消息堆積的能力，那么就不能把它看做是一個合格的消息中間件。

消息堆積分內存式堆積和磁盤式堆積。

RabbitMQ是典型的內存式堆積，但這并非絕對，在某些條件觸發后會有換頁動作來將內存中的消息換頁到磁盤(換頁動作會影響吞吐)，或者直接使用惰性隊列來將消息直接持久化至磁盤中。

Kafka是一種典型的磁盤式堆積，所有的消息都存儲在磁盤中。一般來說，磁盤的容量會比內存的容量要大得多，對于磁盤式的堆積其堆積能力就是整個磁盤的大小。

從另外一個角度講，消息堆積也為消息中間件提供了冗余存儲的功能。

1.9 消息追蹤

對于分布式架構系統中的鏈路追蹤(trace)而言，大家一定不會陌生。

對于消息中間件而言，消息的鏈路追蹤(以下簡稱消息追蹤)同樣重要。

對于消息追蹤最通俗的理解就是要知道消息從哪來，存在哪里以及發往哪里去?；诖斯δ芟?#xff0c;我們可以對發送或者消費完的消息進行鏈路追蹤服務，進而可以進行問題的快速定位與排查。

1.10 消息過濾

消息過濾是指按照既定的過濾規則為下游用戶提供指定類別的消息。

就以kafka而言，完全可以將不同類別的消息發送至不同的topic中，由此可以實現某種意義的消息過濾，或者Kafka還可以根據分區對同一個topic中的消息進行分類。不過更加嚴格意義上的消息過濾應該是對既定的消息采取一定的方式按照一定的過濾規則進行過濾。同樣以Kafka為例，可以通過客戶端提供的ConsumerInterceptor接口或者Kafka Stream的filter功能進行消息過濾。

1.11 多租戶

也可以稱為多重租賃技術，是一種軟件架構技術，主要用來實現多用戶的環境下公用相同的系統或程序組件，并且仍可以確保各用戶間數據的隔離性。

RabbitMQ就能夠支持多租戶技術，每一個租戶表示為一個vhost，其本質上是一個獨立的小型RabbitMQ服務器，又有自己獨立的隊列、交換器及綁定關系等，并且它擁有自己獨立的權限。vhost就像是物理機中的虛擬機一樣，它們在各個實例間提供邏輯上的分離，為不同程序安全保密地允許數據，它既能將同一個RabbitMQ中的眾多客戶區分開，又可以避免隊列和交換器等命名沖突。

1.12 多協議支持

消息是信息的載體，為了讓生產者和消費者都能理解所承載的信息(生產者需要知道如何構造消息，消費者需要知道如何解析消息)，它們就需要按照一種統一的格式描述消息，這種統一的格式稱之為消息協議。有效的消息一定具有某種格式，而沒有格式的消息是沒有意義的。一般消息層面的協議有AMQP、MQTT、STOMP、XMPP等(消息領域中的JMS更多的是一個規范而不是一個協議)，支持的協議越多其應用范圍就會越廣，通用性越強。

比如RabbitMQ能夠支持MQTT協議就讓其在物聯網應用中獲得一席之地。還有的消息中間件是基于其本身的私有協議運轉的，典型的如Kafka。

1.13 跨語言支持

對很多公司而言，其技術棧體系中會有多種編程語言，如C/C++、Java、Go、PHP等，消息中間件本身具備應用解耦的特性，如果能夠進一步的支持多客戶端語言，那么就可以將此特性的效能擴大?？缯Z言的支持力度也可以從側面反映出一個消息中間件的流行程度。

1.14 流量控制

流量控制(flow control)針對的是發送方和接收方速度不匹配的問題，提供一種速度匹配服務抑制發送速率使接收方應用程序的讀取速率與之相適應。

通常的流控方法有Stop-and-wait、滑動窗口以及令牌桶等。

1.15 消息順序性

顧名思義，消息順序性是指保證消息有序。

這個功能有個很常見的應用場景就是CDC(Change DataChapture)，以MySQL為例，如果其傳輸的binlog的順序出錯，比如原本是先對一條數據加1，然后再乘以2，發送錯序之后就變成了先乘以2后加1了，造成了數據不一致。

1.16 安全機制

在Kafka 0.9版本之后就開始增加了身份認證和權限控制兩種安全機制。身份認證是指客戶端與服務端連接進行身份認證，包括客戶端與Broker之間、Broker與Broker之間、Broker與ZooKeeper之間的連接認證，目前支持SSL、SASL等認證機制。權限控制是指對客戶端的讀寫操作進行權限控制，包括對消息或Kafka集群操作權限控制。權限控制是可插拔的，并支持與外部的授權服務進行集成。對于RabbitMQ而言，其同樣提供身份認證(TLS/SSL、SASL)和權限控制(讀寫操作)的安全機制。

1.17 消息冪等性

對于確保消息在生產者和消費者之間進行傳輸而言一般有三種傳輸保障(deliveryguarantee)：

At most once，至多一次，消息可能丟失，但絕不會重復傳輸；

At least once，至少一次，消息絕不會丟，但是可能會重復；

Exactly once，精確一次，每條消息肯定會被傳輸一次且僅一次。

對于大多數消息中間件而言，一般只提供At most once和At least once兩種傳輸保障，對于第三種一般很難做到，由此消息冪等性也很難保證。

Kafka自0.11版本開始引入了冪等性和事務，Kafka的冪等性是指單個生產者對于單分區單會話的冪等，而事務可以保證原子性地寫入到多個分區，即寫入到多個分區的消息要么全部成功，要么全部回滾，這兩個功能加起來可以讓Kafka具備EOS(Exactly Once Semantic)的能力。

不過如果要考慮全局的冪等，還需要與從上下游方面綜合考慮，即關聯業務層面，冪等處理本身也是業務層面所需要考慮的重要議題。以下游消費者層面為例，有可能消費者消費完一條消息之后沒有來得及確認消息就發生異常，等到恢復之后又得重新消費原來消費過的那條消息，那么這種類型的消息冪等是無法有消息中間件層面來保證的。

如果要保證全局的冪等，需要引入更多的外部資源來保證，比如以流水號作為唯一性標識，并且在下游設置一個去重表。

1.18 事務性消息

事務本身是一個并不陌生的詞匯，事務是由事務開始(Begin Transaction)和事務結束(End Transaction)之間執行的全體操作組成。支持事務的消息中間件并不在少數，Kafka和RabbitMQ都支持，不過此兩者的事務是指生產者發生消息的事務，要么發送成功，要么發送失敗。消息中間件可以作為用來實現分布式事務的一種手段，但其本身并不提供全局分布式事務的功能。

2. 性能

功能維度是消息中間件選型中的一個重要的參考維度，但這并不是唯一的維度。有時候性能比功能還要重要，況且性能和功能很多時候是相悖的，魚和熊掌不可兼得，Kafka在開啟冪等、事務功能的時候會使其性能降低，RabbitMQ在開啟rabbitmq_tracing插件的時候也會極大的影響其性能。

消息中間件的性能一般是指其吞吐量，雖然從功能維度上來說，RabbitMQ的優勢要大于Kafka，但是Kafka的吞吐量要比RabbitMQ高出1至2個數量級，一般RabbitMQ的單機QPS在萬級別之內，而Kafka的單機QPS可以維持在十萬級別，甚至可以達到百萬級。

消息中間件的吞吐量始終會受到硬件層面的限制。

就以網卡帶寬為例，如果單機單網卡的帶寬為1Gbps，如果要達到百萬級的吞吐，那么消息體大小不得超過(1Gb/8)/100W，即約等于134B，換句話說如果消息體大小超過134B，那么就不可能達到百萬級別的吞吐。這種計算方式同樣可以適用于內存和磁盤。

時延作為性能維度的一個重要指標，卻往往在消息中間件領域所被忽視，因為一般使用消息中間件的場景對時效性的要求并不是很高，如果要求時效性完全可以采用RPC的方式實現。

消息中間件具備消息堆積的能力，消息堆積越大也就意味著端到端的時延也就越長，與此同時延時隊列也是某些消息中間件的一大特色。

那么為什么還要關注消息中間件的時延問題呢？消息中間件能夠解耦系統，對于一個時延較低的消息中間件而言，它可以讓上游生產者發送消息之后可以迅速的返回，也可以讓消費者更加快速的獲取到消息，在沒有堆積的情況下可以讓整體上下游的應用之間的級聯動作更加高效，雖然不建議在時效性很高的場景下使用消息中間件，但是如果所使用的消息中間件的時延方面比較優秀，那么對于整體系統的性能將會是一個不小的提升。

3. 可靠性與可用性

消息丟失是使用消息中間件時所不得不面對的一個同點，其背后消息可靠性也是衡量消息中間件好壞的一個關鍵因素。

尤其是在金融支付領域，消息可靠性尤為重要。

然而說到可靠性必然要說到可用性，注意這兩者之間的區別，消息中間件的可靠性是指對消息不丟失的保障程度；而消息中間件的可用性是指無故障運行的時間百分比，通常用幾個9來衡量。

從狹義的角度來說，分布式系統架構是一致性協議理論的應用實現，對于消息可靠性和可用性而言也可以追溯到消息中間件背后的一致性協議。

對于Kafka而言，其采用的是類似PacificA的一致性協議，通過ISR(In-Sync-Replica)來保證多副本之間的同步，并且支持強一致性語義(通過acks實現)。

對應的RabbitMQ是通過鏡像環形隊列實現多副本及強一致性語義的。多副本可以保證在master節點宕機異常之后可以提升slave作為新的master而繼續提供服務來保障可用性。

Kafka設計之初是為日志處理而生，給人們留下了數據可靠性要求不要的不良印象，但是隨著版本的升級優化，其可靠性得到極大的增強。

就目前而言，在金融支付領域使用RabbitMQ居多，而在日志處理、大數據等方面Kafka使用居多，隨著RabbitMQ性能的不斷提升和Kafka可靠性的進一步增強，相信彼此都能在以前不擅長的領域分得一杯羹。

同步刷盤是增強一個組件可靠性的有效方式，消息中間件也不例外，Kafka和RabbitMQ都可以支持同步刷盤。

這里還要提及的一個方面是擴展能力，這里我狹隘地將此歸納到可用性這一維度，消息中間件的擴展能力能夠增強其用可用能力及范圍，比如前面提到的RabbitMQ支持多種消息協議，這個就是基于其插件化的擴展實現。還有從集群部署上來講，歸功于Kafka的水平擴展能力，其基本上可以達到線性容量提升的水平，在LinkedIn實踐介紹中就提及了有部署超過千臺設備的Kafka集群。

4. 運維管理

在消息中間件的使用過程中難免會出現各式各樣的異常情況，有客戶端的，也有服務端的，那么怎樣及時有效的進行監測及修復？業務線流量有峰值又低谷，尤其是電商領域，那么怎樣前進行有效的容量評估，尤其是大促期間？腳踢電源、網線被挖等事件層出不窮，如何有效的做好異地多活？這些都離不開消息中間件的衍生產品——運維管理。

運維管理也可以進行進一步的細分，比如：申請、審核、監控、告警、管理、容災、部署等。

申請、審核很好理解，在源頭對資源進行管控，既可以進行有效校正應用方的使用規范，配和監控也可以做好流量統計與流量評估工作，一般申請、審核與公司內部系統交融性較大，不適合使用開源類的產品。

監控、告警也比較好理解，對消息中間件的使用進行全方位的監控，即可以為系統提供基準數據，也可以在檢測到異常的情況配合告警，以便運維、開發人員的迅速介入。除了一般的監控項(比如硬件、GC等)之外，對于消息中間件還需要關注端到端時延、消息審計、消息堆積等方面。

不管是擴容、降級、版本升級、集群節點部署、還是故障處理都離不開管理工具的應用，一個配套完備的管理工具集可以在遇到變更時做到事半功倍。

故障可大可小，一般是一些應用異常，也可以是機器掉電、網絡異常、磁盤損壞等單機故障，這些故障單機房內的多副本足以應付。如果是機房故障就要涉及異地容災了，關鍵點在于如何有效的進行數據復制。

5. 社區力度及生態發展

對于目前流行的編程語言而言，如Java、Python，如果你在使用過程中遇到了一些異常，基本上可以通過搜索引擎的幫助來得到解決，因為一個產品用的人越多，踩過的坑也就越多，對應的解決方案也就越多。

對于消息中間件也同樣適用，如果你選擇了一種“生僻”的消息中間件，可能在某些方面運用的得心應手，但是版本更新緩慢、遇到棘手問題也難以得到社區的支持而越陷越深；相反如果你選擇了一種“流行”的消息中間件，其更新力度大，不僅可以迅速的彌補之前的不足，而且也能順應技術的快速發展來變更一些新的功能，這樣可以讓你以“站在巨人的肩膀上”。

在運維管理維度我們提及了Kafka和RabbitMQ都有一系列開源的監控管理產品，這些正是得益于其社區及生態的迅猛發展。

舉例：RocketMQ與Kafka的選型

RocketMQ顯著特性：支持延遲發送、延遲消費、廣播消費、消息軌跡、重試隊列、死信隊列等，以上特性Kafka均不支持。

Kafka顯著特性：大數據組件廣泛應用、流式處理組件廣泛應用、高吞吐、一個集群常見的百萬TPS，此特性RocketMQ無法企及。

RocketMQ場景有：支付類、訂單類、業務通知類等。

Kafka場景有：日志埋點、大數據處理等。

-End-

點亮?“再看”?，與好友一起分享吧

總結

以上是生活随笔為你收集整理的weblogic jms消息 删除_消息队列与消息中间件概述：消息中间件核心概念与技术选型...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。