MQ消息隊列的12點核心原理總結

1. 消息生產者、消息者、隊列

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

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

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

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

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

3. 點對點消息隊列模型

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

file

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

  • 消息隊列(Queue)
  • 發送者(Sender)
  • 接收者(Receiver)

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

特點

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

4. 發佈訂閱消息模型Topic

file

發佈訂閱模型包含三個角色:

  • 主題(Topic)
  • 發佈者(Publisher)
  • 訂閱者(Subscriber)

多個發佈者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。

特點

  • 每個消息可以有多個消費者:和點對點方式不同,發佈消息可以被所有訂閱者消費
  • 發佈者和訂閱者之間有時間上的依賴性。
  • 針對某個主題(Topic)的訂閱者,它必須創建一個訂閱者之後,才能消費發佈者的消息。
  • 爲了消費消息,訂閱者必須保持運行的狀態。
5.點對點和發佈訂閱的區別

生產者發送一條消息到隊列queue,只有一個消費者能收到。

發佈者發送到topic的消息,只有訂閱了topic的訂閱者纔會收到消息。

file

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.消息隊列的選型和應用場景

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章