RocketMQ消息隊列介紹與應用

RocketMQ簡單介紹

RocketMQ是一個消息中間件，MQ的主要特點為解耦、異步、削峰，具有高性能、高可靠、高實時、分布式特點，用于減少資料庫壓力的業務場景，其中RocketMQ的核心元件概念如下：

支援嚴格的消息順序

支援Topic與Queue兩種模式

億級消息堆積能力

支援多種消息協定，如 JMS、MQTT 等

分布式高可用的部署架構,滿足至少一次消息傳遞語義

提供 docker 鏡像用于隔離測試和雲叢集部署

提供配置、名額和監控等功能豐富的 Dashboard

RocketMQ結構

Name Server：注冊中心（zookeeper）頻繁更新offset。

Producer：消息生産者 生産消息 寄件人。

Consumer：消息消費者、複制消息消費、收件人。

Broker：中介（郵政） 提供消息中轉服務。

Group ：分組好處（業務區分，便于管理）。

Tag：多個标簽 where 。

Key：區分業務系統 。

Msgid： broker在這個系統中它是獨一無二的。

PS：消息中間件的最重要的作用是異步和解耦。

圖中箭頭的含義

從 Broker 開始，Broker Master1 和 Broker Slave1 是主從結構，它們之間會進行資料同步，即 Date Sync。同時每個 Broker 與

NameServer 叢集中的所有節點建立長連接配接，定時注冊 Topic 資訊到所有 NameServer 中。

Producer 與 NameServer 叢集中的其中一個節點（随機選擇）建立長連接配接，定期從 NameServer 擷取 Topic 路由資訊，并向提供 Topic 服務的 Broker Master 建立長連接配接，且定時向 Broker 發送心跳。Producer 隻能将消息發送到 Broker master，但是 Consumer 則不一樣，它同時和提供 Topic 服務的 Master 和 Slave

建立長連接配接，既可以從 Broker Master 訂閱消息，也可以從 Broker Slave 訂閱消息。

RocketMQ事務消息設計思路

應用子產品遇到要發送事務消息的場景時，先發送prepare消息給MQ。

prepare消息發送成功後，應用子產品執行資料庫事務（本地事務）。

根據資料庫事務執行的結果，再傳回Commit或Rollback給MQ。

如果是Commit，MQ把消息下發給Consumer端，如果是Rollback，直接删掉prepare消息。

第3步的執行結果如果沒響應，或是逾時的，啟動定時任務回查事務狀态（最多重試15次，超過了 預設丢棄此消息），處理結果同第4步。

MQ消費的成功機制由MQ自己保證。

業務案例

有一個點贊業務，不限制使用者的點贊數隻需進行記錄(産品需求，開發提議無效)，當每個使用者都進行x連擊享受數量猛增的快感時如果資料庫都需要進行x個點贊資料的插入，資料庫毫無疑問會塞死導緻崩潰。

于是想到可以嘗試下MQ削峰，比如每秒來了5000消息但資料庫隻能承受2000，那我消費時每次隻拉取消費1600就好了，剩下的放在Broker堆積慢慢消費就好。由于之前的消息中心也在用RocketMQ，于是确認使用RocketMQ來進行削峰。

五、結束語

本篇簡單介紹了Rocket基本的設計思路和流程，注意要保證資料可靠，需采用同步刷盤和同步雙寫的方式，但性能會較其他方式低，文章内有任何不正确或不詳盡之處請留言指導，謝謝。