訊息佇列MQ核心原理全面總結(11大必會原理)

mikechen的網際網路架構發表於2022-09-22

MQ訊息佇列的12點核心原理總結-mikechen的網際網路架構

訊息佇列已經逐漸成為分散式應用場景、內部通訊、以及秒殺等高併發業務場景的核心手段,它具有低耦合、可靠投遞、廣播、流量控制、最終一致性 等一系列功能。

無論是 RabbitMQ、RocketMQ、ActiveMQ、Kafka還是其它等,都有的一些基本原理、術語、機制等,總結分享出來,希望大家在使用 訊息佇列技術的時候能夠快速理解@mikechen。

1. 訊息生產者、訊息者、佇列

  •  訊息生產者Producer:傳送訊息到 訊息佇列
  •  訊息消費者Consumer:從 訊息佇列接收訊息。
  •  Broker:概念來自與Apache ActiveMQ,指MQ的服務端,幫你把訊息從傳送端傳送到接收端。
  •   訊息佇列Queue:一個先進先出的訊息儲存區域。訊息按照順序傳送接收,一旦訊息被消費處理,該訊息將從佇列中刪除。

2.設計Broker主要考慮

1)訊息的轉儲:在更合適的時間點投遞,或者透過一系列手段輔助訊息最終能送達消費機。

2)規範一種正規化和通用的模式,以滿足解耦、最終一致性、錯峰等需求。

3)其實簡單理解就是一個訊息轉發器,把一次RPC做成兩次RPC。傳送者把訊息投遞到broker,broker再將訊息轉發一手到接收端。

總結起來就是兩次RPC加一次轉儲,如果要做消費確認,則是三次RPC。

3. 點對點 訊息佇列模型

點對點模型 用於 訊息生產者 和 訊息消費者 之間 點到點 的通訊。

MQ訊息佇列的12點核心原理總結-mikechen的網際網路架構

點對點模式包含三個角色:

  •   訊息佇列(Queue)
  •   傳送者(Sender)
  •   接收者(Receiver)

每個訊息都被髮送到一個特定的佇列,接收者從佇列中獲取訊息。佇列保留著訊息,可以放在 記憶體 中也可以 持久化,直到他們被消費或超時。

特點

  •  每個訊息只有一個消費者(Consumer)(即一旦被消費,訊息就不再在訊息佇列中)
  •  傳送者和接收者之間在時間上沒有依賴性
  •  接收者在成功接收訊息之後需向佇列應答成功

4. 釋出訂閱訊息模型Topic

MQ訊息佇列的12點核心原理總結-mikechen的網際網路架構

釋出訂閱模型包含三個角色:

  •   主題(Topic)
  •   釋出者(Publisher)
  •   訂閱者(Subscriber)

多個釋出者將訊息傳送到Topic,系統將這些訊息傳遞給多個訂閱者。

特點

  •  每個訊息可以有多個消費者:和點對點方式不同,釋出訊息可以被所有訂閱者消費
  •  釋出者和訂閱者之間有時間上的依賴性。
  •  針對某個主題(Topic)的訂閱者,它必須建立一個訂閱者之後,才能消費釋出者的訊息。
  •  為了消費訊息,訂閱者必須保持執行的狀態。

5.點對點和釋出訂閱的區別

生產者傳送一條訊息到佇列queue,只有一個消費者能收到。

釋出者傳送到topic的訊息,只有訂閱了topic的訂閱者才會收到訊息。

6. 訊息的順序性保證

基於Queue訊息模型,利用FIFO先進先出的特性,可以保證訊息的順序性。

7. 訊息的ACK機制

即訊息的Ackownledge確認機制,

為了保證訊息不丟失,訊息佇列提供了訊息Acknowledge機制,即ACK機制,當Consumer確認訊息已經被消費處理,傳送一個ACK給訊息佇列,此時訊息佇列便可以刪除這個消

息了。如果Consumer當機/關閉,沒有傳送ACK,訊息佇列將認為這個訊息沒有被處理,會將這個訊息重新傳送給其他的Consumer重新消費處理。

8.最終一致性的設計思路

主要是用“記錄”和“補償”的方式。

本地事務維護業務變化和通知訊息,一起落地,然後RPC到達broker,在broker成功落地後,RPC返回成功,本地訊息可以刪除。否則本地訊息一直靠定時任務輪詢不斷重發,這樣就保證了訊息可靠落地broker。

broker往consumer傳送訊息的過程類似,一直髮送訊息,直到consumer傳送消費成功確認。

我們先不理會重複訊息的問題,透過兩次訊息落地加補償,下游是一定可以收到訊息的。然後依賴狀態機版本號等方式做判重,更新自己的業務,就實現了最終一致性。

如果出現消費方處理過慢消費不過來,要允許消費方主動ack error,並可以與broker約定下次投遞的時間。

對於broker投遞到consumer的訊息,由於不確定丟失是在業務處理過程中還是訊息傳送丟失的情況下,有必要記錄下投遞的IP地址。決定重發之前詢問這個IP,訊息處理成功了嗎?如果詢問無果,再重發。

事務:本地事務,本地落地,補償傳送。本地事務做的,是業務落地和訊息落地的事務,而不是業務落地和RPC成功的事務。訊息只要成功落地,很大程度上就沒有丟失的風險。

9. 訊息的事務支援

訊息的收發處理支援事務,例如:在任務中心場景中,一次處理可能涉及多個訊息的接收、處理,這應該處於同一個事務範圍內,如果一個訊息處理失敗,事務回滾,訊息重新回到佇列中。

10. 訊息的持久化

訊息的持久化,對於一些關鍵的核心業務來說是非常重要的,啟用訊息持久化後,訊息佇列當機重啟後,訊息可以從持久化儲存恢復,訊息不丟失,可以繼續消費處理。

11. 訊息佇列的高可用性

在實際生產環境中,使用單個例項的訊息佇列服務,如果遇到當機、重啟等系統問題,訊息佇列就無法提供服務了,因此很多場景下,我們希望訊息佇列有高可用性支援,例如

RabbitMQ的映象叢集模式的高可用性方案,ActiveMQ也有基於LevelDB+ZooKeeper的高可用性方案,以及Kafka的Replication機制等。

12.訊息佇列的選型和應用場景

具體請參考: 高併發架構系列:分散式之訊息佇列的特點、選型、及應用場景詳解

以上

作者簡介

陳睿| ,10年+大廠架構經驗,《BAT架構技術500期》系列文章作者,分享十餘年架構經驗以及面試心得!

閱讀mikechen的網際網路架構更多技術文章合集

| | | | | | | 架構師

關注「mikechen 的網際網路架構」公眾號,回覆 【架構】領取我原創的《300 期 + BAT 架構技術系列與 1000 + 大廠面試題答案》


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70011997/viewspace-2915722/,如需轉載,請註明出處,否則將追究法律責任。

相關文章