怎么理解RabbitMQ在一線大廠中的基礎組件架構設計思路

這篇文章將為大家詳細講解有關怎么理解RabbitMQ在一線大廠中的基礎組件架構設計思路，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

1、MQ組件實現功能點

MQ組件實現功能點
1) 支持消息高性能的序列化轉換、異步化發送消息
2) 支持消息生產實例與消費實例的連接池化緩存化,提升性能
3) 支持可靠性投遞消息,保證消息的100%不丟失
4) 支持消費端的冪等操作,避免消費端重復消費問題

5) 支持迅速消息發送模式,有些場景下不需要保證100%成功投遞,在一些日志收集、統計分析等需求下可以保證高性能、超高吞吐量
6) 支持延遲消息模式,消息可以延遲發送,指定延遲時間,用于某些延遲檢查、服務限流場景
7) 支持事務消息,且100%保障可靠性投遞,在金融行業單筆大金額操作時會有此類需求
8) 支持順序消息,保證消息送達消費端的前后順序,例如下訂單等復合型操作
9) 支持消息補償、重試,快速定位異常

2、迅速消息發送

   迅速消息發送是指消息不進行落庫存儲,不做可靠性保證. 在一些非核心消息、日志數據、或者統計分析等場景下比較合適. 迅速消息
的優點就是性能最高,吞吐量最大

3、批量消息發送

   批量消息是指我們把消息放到一個集合里統一進行提交,將消息合并,對于channel而言,就是發送一次消息,這種方式也是希望消費端在
消費的時候,可以進行批量化消費,但是不保證可靠性,需要進行補償機制RabbitMQ不支持消息批量發送,可以自己實現

4、延遲消息發送

   延遲消息相對簡單,就是我們在Message封裝的時候添加delayTime屬性即可,使得我們消息可以進行延遲發送,根據具體的業務場景可以
很好的用到!
場景舉例:
1) 比如在電商平臺買到的商品簽收后,不點擊確認支付,那么系統自動會在7天去進行支付操作
2) 還有一些自動超時作廢的場景,如優惠券/紅包有使用時間限制,也可以使用延遲消息機制

5、順序消息發送

要保障以下幾點：
1) 發送的順序消息,必須保障消息投遞到同一個隊列,且這個消費者只能有一個(獨占模式)
2) 然后需要統一提交(可能是合并成一個大消息,也可以是拆分成多個小消息),并且所有消息的會話ID一致
3) 添加消息的屬性:順序標記的序號、本次順序消息的SIZE屬性,先不消費消息,消費端收到后進行消息落庫
4) 并行進行發送給自身的延遲消息,注意帶上關鍵屬性(會話ID、SIZE)進行后續處理消費,確保延遲的事件段中這一批消息都已經全部收到
5) 當收到延遲消息后,根據會話ID、SIZE抽取數據庫數據進行處理即可
6) 定時輪詢補償機制,對于異常情況,如生產端消息沒有完全投遞成功、或者消費端落庫異常,導致消費端落庫后缺少消息條目的情況

6、事務消息發送

我們采用類似可靠性投遞的機制,也就是補償機制.

我們使用的數據源必須是同一個,也就是業務操作DB1數據庫和消息記錄DB2數據庫使用同一個數據源

然后重寫Spring DataSourceTransactionManager,在本地事務提交的時候進行發送消息,但是也有可能事務提交成功但是消息發送失敗,這個
時候就需要進行補償了

7、消息的冪等性

可能導致消息出現非冪等的原因:
1) 可靠性消息投遞機制
2) MQ Broker服務與消費端傳輸消息的過程中的網絡抖動
3) 消費端故障或異常

關于怎么理解RabbitMQ在一線大廠中的基礎組件架構設計思路就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。