RocketMQ 學習筆記

簡介：

RocketMQ（Metaq3.0版本更名）是一款分佈式隊列模型的消息中間件 特色以下：

1.保證消息順序
2.支持消息拉取模式
3.高效的訂閱者水平和擴展能力
4.實時的消息訂閱機制
5.億級的消息堆積能力

RocketMQ低延遲、高可靠、可伸縮、易於使用的消息中間件。具備如下特性：

1.強調集羣無單點，可擴展，任意一點高可用，水平可擴展。
2.海量消息堆積能力，且堆積後寫入低延遲。
3.支持上萬個隊列。（api豐富）
4.消息失敗重試機制。
5.消息可查詢。
6.開源社區活躍，成熟度高（雙十一訪問壓力）。-- oceanbase
7.支持發佈/訂閱（Pub/Sub）和點對點（P2P）消息模型
8.在一個隊列中可靠的先進先出（FIFO）和嚴格的順序傳遞
9.支持拉（pull）和推（push）兩種消息模式
10.單一隊列百萬消息的堆積能力
11.支持多種消息協議，如 JMS、MQTT 等
12.分佈式高可用的部署架構,知足至少一次消息傳遞語義
13.提供 docker 鏡像用於隔離測試和雲集羣部署
14.提供配置、指標和監控等功能豐富的 Dashboard

## 專業術語

Producer

消息生產者，生產者的做用就是將消息發送到
MQ，生產者自己既能夠產生消息，如讀取文本信息等。也能夠對外提供接口，由外部應用來調用接口，再由生產者將收到的消息發送到
MQ。

Producer Group

生產者組，簡單來講就是多個發送同一類消息的生產者稱之爲一個生產者組。在這裏能夠不用關心，只要知道有這麼一個概念便可。

Consumer

消息消費者，簡單來講，消費 MQ
上的消息的應用程序就是消費者，至於消息是否進行邏輯處理，仍是直接存儲到數據庫等取決於業務須要。

Consumer Group

消費者組，和生產者相似，消費同一類消息的多個 consumer 實例組成一個消費者組。

Topic

Topic是一種消息的邏輯分類，好比說你有訂單類的消息，也有庫存類的消息，那麼就須要進行分類，一個是訂單 Topic 存放訂單相關的消息，一個是庫存 Topic 存儲庫存相關的消息。

Message

Message 是消息的載體。一個 Message 必須指定 topic，至關於寄信的地址。Message
還有一個可選的 tag 設置，以便消費端能夠基於 tag 進行過濾消息。也能夠添加額外的鍵值對，例如你須要一個業務 key 來查找 broker
上的消息，方便在開發過程當中診斷問題。

Tag

標籤能夠被認爲是對 Topic 進一步細化。通常在相同業務模塊中經過引入標籤來標記不一樣用途的消息。

Broker

Broker 是 RocketMQ 系統的主要角色，其實就是前面一直說的 MQ。Broker
接收來自生產者的消息，儲存以及爲消費者拉取消息的請求作好準備。

Name Server

Name Server 爲 producer 和 consumer 提供路由信息。

RocketMQ 架構

由這張圖能夠看到有四個集羣，分別是 NameServer 集羣、Broker 集羣、Producer 集羣和
Consumer 集羣：

1.  NameServer: 提供輕量級的服務發現和路由。 每一個 NameServer
    記錄完整的路由信息，提供等效的讀寫服務，並支持快速存儲擴展。

2.  Broker: 經過提供輕量級的 Topic 和 Queue
    機制來處理消息存儲,同時支持推（push）和拉（pull）模式以及主從結構的容錯機制。

3.  Producer：生產者，產生消息的實例，擁有相同 Producer Group 的 Producer
    組成一個集羣。

4.  Consumer：消費者，接收消息進行消費的實例，擁有相同 Consumer Group 的  
    Consumer 組成一個集羣。

簡單說明一下圖中箭頭含義，從 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 集羣部署模式

1.  單 master 模式  
    也就是隻有一個 master 節點，稱不上是集羣，一旦這個 master
    節點宕機，那麼整個服務就不可用，適合我的學習使用。

2.  多 master 模式  
    多個 master 節點組成集羣，單個 master 節點宕機或者重啓對應用沒有影響。  
    優勢：全部模式中性能最高  
    缺點：單個 master
    節點宕機期間，未被消費的消息在節點恢復以前不可用，消息的實時性就受到影響。  
    **注意**：使用同步刷盤能夠保證消息不丟失，同時 Topic 相對應的 queue
    應該分佈在集羣中各個節點，而不是隻在某各節點上，不然，該節點宕機會對訂閱該
    topic 的應用形成影響。

3.  多 master 多 slave 異步複製模式  
    在多 master 模式的基礎上，每一個 master 節點都有至少一個對應的 slave。master  
    節點可讀可寫，可是 slave 只能讀不能寫，相似於 mysql 的主備模式。  
    優勢： 在 master 宕機時，消費者能夠從 slave
    讀取消息，消息的實時性不會受影響，性能幾乎和多 master 同樣。  
    缺點：使用異步複製的同步方式有可能會有消息丟失的問題。

4.  多 master 多 slave 同步雙寫模式  
    同多 master 多 slave 異步複製模式相似，區別在於 master 和 slave
    之間的數據同步方式。  
    優勢：同步雙寫的同步模式能保證數據不丟失。  
    缺點：發送單個消息 RT 會略長，性能相比異步複製低10%左右。  
    刷盤策略：同步刷盤和異步刷盤（指的是節點自身數據是同步仍是異步存儲）  
    同步方式：同步雙寫和異步複製（指的一組 master 和 slave 之間數據的同步）

注意：要保證數據可靠，需採用同步刷盤和同步雙寫的方式，但性能會較其餘方式低。

用戶指南：

鏈接地址：https://files.cnblogs.com/files/ldy-blogs/RocketMQ_userguide.pdf