目錄
1 前言
分享互聯網大廠的基礎組件架構封裝思路，
其中涉及到
- 消息發送的多模式化、
- 消息的高性能序列化、
- 消息的異步化、
- 連接的緩存容器、
- 消息的可靠性投遞、補償策略、
- 消息的冪等解決方案
2 一線大廠的MQ組件實現思路和架構設計思路
- 支持高性能的序列化轉換, 異步化發送消息
- 支持消息生產實例與消費實例的鏈接池化緩存化, 提升性能
- 支持可靠性投遞消息, 保障消息100%不丟失
- 支持消費端的冪等操作, 避免消費端重複消費的問題
- 支持迅速消息發送模式, 在一些日誌收集/統計分析等需求下可以保證高性能, 高吞吐量
- 支持延遲消息模式, 消息可以延遲發送, 指定延遲時間, 用於某些延遲檢查, 服務限流場景
- 支持事務消息, 器100%保障可靠性投遞, 在金融行業單筆大金額操作時會有此類需求
- 支持順序消息, 保證消息送達消費端的先後順序
- 支持消息補償, 重試, 以及快速定位異常/失敗消息
- 支持集羣消息負載均衡, 保障消息落到具體SET集羣的負載均衡
- 支持消息路由策略, 指定某些消息路由到指定的SET集羣
3 基礎MQ消息組件設計思路-1（迅速，確認，批量，延遲）
迅速消息發送
- 迅速消息是指消息不進行落庫存儲, 不做可靠性的保障
- 在一些非核心消息, 日誌數據, 或者統計分析等場景下比較合適
- 迅速消息的優點就是性能最高, 吞吐量最大
確認消息發送
- step1, step2 : 業務信息和消息信息入庫
- step3 : 消息發送到MQ Broker
- step4 : Broker回送一個ACK確認消息
- step5 : 更新DB中消息狀態
- step6 : 定時任務讀取中間狀態消息
- step7 : 執行消息重發
- step8 : 重發多次依舊失敗的消息, 將其置爲失敗終態
批量消息發送
批量消息是指我們把消息放到一個集合裏統一進行提交, 這種方案設計思路是期望消息在一個會話裏, 比如投遞到threadlocal裏的集合, 然後擁有相同的會話ID, 並且帶有這次提交消息的SIZE等相關相關屬性, 最重要的一點是要把這一批消息進行合併。對於Channel而言, 就是發送一次消息。這種方式也是希望消費端在消費的時候, 可以進行批量化的消費, 針對於某一個原子業務的操作去處理, 但是不保障可靠性, 需要進行補償機制。
- step1 : 業務數據入庫
- step2 : 消息組裝之後進行統一入庫(如果不需要可靠性投遞的話, 可以省略)
- step3 : 消息發送到Broker
- step4-step8基本和確認消息是一致的,如果不需要可靠性投遞的話, 是可以省略的
延遲消息發送
- 延遲消息就是在Message封裝的時候, 添加delayTime屬性即可, 使得我們的消息可以進行延遲發送1
4 基礎MQ消息組件設計思路-2（順序）
順序消息有點類似於批量消息的實現機制, 但是有些不同, 順序消息需要保障一下幾點:
- 發送的順序消息, 必須保障消息投遞到同一個隊列, 且這個消費者只能有一個(獨佔模式)
- 然後需要統一提交(可能是合併成一個大的消息, 也可能是拆分爲多個消息), 並且所有消息的會話ID要一致
- 添加消息屬性 : 順序標記的序號, 和本次順序消息的SIZE屬性, 進行落庫操作
- 並行進行發送給自身的延遲消息(帶上關鍵屬性 : 會話ID, SIZE)進行後續處理消費
- 當收到延遲消息後, 根據會話ID, SIZE抽取數據庫數據進行處理即可
- 定時輪詢補償機制, 對於異常情況(如生產端消息沒有完全投遞成功或者消費端落庫異常導致消費端落庫後缺少消息條目的情況)進行補償
5 基礎MQ消息組件設計思路-3(事務)
- 事務消息, 使用相對較少
- 爲了保障性能的同時, 也支持事務。並不推薦選擇傳統的RabbitMQ事務和Spring集成的機制, 因爲在性能測試過程中, 這種方式性能並不理想, 非常消耗系統資源, 且會出現阻塞等情況, 高峯期也是一定程度上影響MQ集羣的性能
- 解決方案 : 採用類似可靠性投遞的機制, 也就是補償機制。但是數據源必須是同一個, 也就是業務操作的數據庫DB1和消息記錄的數據庫DB2使用同一個數據庫, 保證DB層的數據一致性
- 然後利用重寫Spring DataSourceTransactionManager, 在本地事務提交的時候進行發送消息, 但是也有可能事務提交成功但是消息發送失敗, 這個時候就需要進行補償了。
6 消息冪等性保障-消息路由規則架構設計思路
可能導致消息出現非冪等性的原因 :
- 可靠性消息投遞機製造成的消息重發
- MQ Broker服務於消費端消息傳輸的過程中出現網絡抖動
- 消費端故障或異常
消息冪等性設計 :
