消息中間件(MQ)的定義

其實并沒有標準定義，一般認為，消息中間件屬于分布式系統中一個子系統，關注于數據的發送和接收，利用高效可靠的異步消息傳遞機制對分布
式系統中的其余各個子系統進行集成。

幾個關鍵詞：

• 高效：對于消息的處理處理速度快。

• 可靠：一般消息中間件都會有消息持久化機制和其他的機制確保消息不丟失。

• 異步：指發送完一個請求，不需要等待返回，隨時可以再發送下一個請求，即不需要等待。

一句話總結，消息中間件不生產消息，只是消息的搬運工。

為什么要用消息中間件？

假設一個電商交易的場景，用戶下單之后調用庫存系統減庫存，然后需要調用物流系統進行發貨，如果交易、庫存、物流是屬于一個系統的，那么
就是接口調用。但是隨著系統的發展，各個模塊越來越龐大、業務邏輯越來越復雜，必然是要做服務化和業務拆分的。這個時候就需要考慮這些系統之
間如何交互，一般的處理方式就是RPC（Remote Procedure Call，具體實現如Dubbo、SpringCloud）。系統繼續發展，可能一筆交易后續需要調用幾十個接
口來執行業務，比如還有風控系統、短信服務等等。這個時候就需要消息中間件登場來解決問題了。

所以消息中間件主要解決分布式系統之間消息的傳遞，同時為分布式系統中其他子系統提供了松耦合的架構，同時還有以下好處：

• 低耦合
  ：不管是程序還是模塊之間，使用消息中間件進行間接通信。

• 異步通信能力：使得子系統之間得以充分執行自己的邏輯而無需等待。

• 緩沖能力：消息中間件像是一個巨大的蓄水池，將高峰期大量的請求存儲下來慢慢交給后臺進行處理，對于秒殺業務來說尤為重要。

• 伸縮性：是指通過不斷向集群中加入服務器的手段來緩解不斷上升的用戶并發訪問壓力和不斷增長的數據存儲需求。就像彈簧掛東西一樣，用
  戶多，伸一點，用戶少，縮一點。衡量架構是否高伸縮性的主要標準就是是否可用多臺服務器構建集群，是否
  容易向集群中添加新的服務器。加入新的服務器后是否可以提供和原來服務器無差別的服務。集群中可容納的總的服務器數量是否有限制。

• 擴展性：主要標準就是在網站增加新的業務產品時，是否可以實現對現有產品透明無影響，不需要任何改動或者很少改動既有業務功能就可以上線
  新產品。比如用戶購買電影票的應用，現在我們要增加一個功能，用戶買了鐵血戰士的票后，隨機抽取用戶送異形的限量周邊。怎么做到不改動用戶購
  票功能的基礎上增加這個功能。熟悉設計模式的同學，應該很眼熟，這是設計模式中的開閉原則（對擴展開放，對修改關閉）在架構層面的一個原則。

和RPC有何區別？

RPC和消息中間件的場景的差異很大程度上在于就是“依賴性”和“同步性”。

• 依賴性：
  比如短信通知服務并不是交易環節必須的，并不影響下單流程，不是強依賴，所以交易系統不應該依賴短信服務。如果是RPC調用，短信通知服
  務掛了，整個業務就掛了，這個就是依賴性導致的，而消息中間件則沒有這個依賴性。
  消息中間件出現以后對于交易場景可能是調用庫存中心等強依賴系統執行業務，之后發布一條消息（這條消息存儲于消息中間件中）。像是短信通
  知服務、數據統計服務等等都是依賴于消息中間件去消費這條消息來完成自己的業務邏輯。

• 同步性：
  RPC方式是典型的同步方式，讓遠程調用像本地調用。消息中間件方式屬于異步方式。

消息中間件有些什么使用場景？

異步處理

場景說明：用戶注冊后，需要發注冊郵件和注冊短信。傳統的做法有兩種 1.串行的方式；2.并行方式。

串行方式：將注冊信息寫入數據庫成功后，發送注冊郵件，再發送注冊短信。以上三個任務全部完成后，返回給客戶端。

并行方式：將注冊信息寫入數據庫成功后，發送注冊郵件的同時，發送注冊短信。以上三個任務完成后，返回給客戶端。與串行的差別是，并
行的方式可以提高處理的時間。

假設三個業務節點每個使用50毫秒鐘，不考慮網絡等其他開銷，則串行方式的時間是150毫秒，并行的時間可能是100毫秒。

小結：如以上案例描述，傳統的方式系統的性能（并發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？

引入消息隊列，將不是必須的業務邏輯，異步處理。

按照以上約定，用戶的響應時間相當于是注冊信息寫入數據庫的時間，也就是 50 毫秒。注冊郵件，發送短信寫入消息隊列后，直接返回，因此寫入
消息隊列的速度很快，基本可以忽略，因此用戶的響應時間可能是50毫秒。因此架構改變后，系統的吞吐量提高到每秒20QPS。比串行提高了3倍，比
并行提高了兩倍。

應用解耦

場景說明：用戶下單后，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用庫存系統的接口。

傳統模式的缺點：

• 假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗；

• 訂單系統與庫存系統耦合；

如何解決以上問題呢？引入應用消息隊列后的方案
：

• 訂單系統：用戶下單后，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功。

• 庫存系統：訂閱下單的消息，采用拉/推的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操作。

假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單后，訂單系統寫入消息隊列就不再關心其他的后續操作了，實現訂單系統與
庫存系統的應用解耦。

流量削峰

流量削峰也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。

應用場景：秒殺活動，一般會因為流量過大，導致流量暴增，應用掛掉。為解決這個問題，一般需要在應用前端加入消息隊列：可以控制活動的人
數；可以緩解短時間內高流量壓垮應用。

用戶的請求，服務器接收后，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面；秒殺業務根據消息隊
列中的請求信息，再做后續處理。

日志處理

日志處理是指將消息隊列用在日志處理中，比如Kafka的應用，解決大量日志傳輸的問題。架構簡化如下：

• 日志采集客戶端：負責日志數據采集，定時寫入Kafka隊列

• Kafka消息隊列：負責日志數據的接收，存儲和轉發

• 日志處理應用：訂閱并消費kafka隊列中的日志數據

消息通訊

消息通訊是指消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。比如實現點對點消息隊列，或者聊天室等。

• 點對點通訊：客戶端A和客戶端B使用同一隊列，進行消息通訊。

• 聊天室通訊：客戶端A，客戶端B，客戶端N訂閱同一主題，進行消息發布和接收。實現類似聊天室效果。

消息中間件的編年史

常見的消息中間件比較

ActiveMQRabbitMQRocketMQKafka

性能	6000+	萬級(12000+)	十萬級	百萬級
消息持久化	支持	支持	支持	支持
多語言支持	支持	支持	很少	支持
社區活躍度	高	高	中	高
支持協議	多（JMS,AMQP…… ）	多（AMQP,STOMP,MQTT…… ）	自定義協議	自定義協議
優點	成熟，已經在很多公司得到應用。較多的文檔。各種協議支持較好，有多個語言的成熟客戶端。	性能較好，管理界面較豐富，在互聯網公司也有較大規模的應用，有多個語言的成熟客戶端。	模型簡單，接口易用。在阿里有大規模應用。分布式系統，性能很好，版本更新很快。	天生分布式，性能最好，所以常見用于大數據領域。
缺點	性能較弱。缺乏大規模吞吐的場景的應用，有江河日下之感。	內部機制很難了解，也意味很難定制和掌控。集群不支持動態擴展。	文檔少，支持的語言較少。	運維難度大，偶爾有數據混亂的情況，對ZooKeeeper強依賴。多副本機制下對帶寬有一定的要求。

如果一般的業務系統要引入 MQ，怎么選型：

• 用戶訪問量在ActiveMQ的可承受范圍內，而且確實主要是基于解耦和異步來用的，可以考慮ActiveMQ，也比較貼近Java工程師的使用習慣，但是
  ActiveMQ現在停止維護了，同時ActiveMQ并發不高，所以業務量一定的情況下可以考慮使用。

• RabbitMQ作為一個純正血統的消息中間件，有著高級消息協議AMQP的完美結合，在消息中間件中地位無可取代，但是erlang語言阻止了我們去深
  入研究和掌控，對公司而言，底層技術無法控制，但是確實是開源的，有比較穩定的支持，活躍度也高。

• 對自己公司技術實力有絕對自信的，可以用RocketMQ。

所以中小型公司，技術實力較為一般，技術挑戰不是特別高，用ActiveMQ、RabbitMQ 是不錯的選擇；大型公司，基礎架構研發實力較強，用RocketMQ
是很好的選擇
；如果是大數據領域的實時計算、日志采集等場景，用Kafka是業內標準的，絕對沒問題，社區活躍度很高，幾乎是全世界這個領域的事實性規范。

整體上來看，使用文件系統的消息中間件（kafka、rokcetMq）性能是最好的，所以基于文件系統存儲的消息中間件是發展趨勢，從存儲方式和效
率來看文件系統>KV存儲>關系型數據庫。

總結

以上是生活随笔為你收集整理的消息中间件简介的全部內容，希望文章能夠幫你解決所遇到的問題。

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