RocketMQ 入門術語

• RocketMQ 網絡部署結構

 　　　　　　　　　　　　

• • Name Server

　　　　　　Name Server 是一個註冊中心，整個分佈式消息調度的總控制，給消息隊列的生產者和消費者提供路由信息，提供輕量級的服務發現，路由，元數據信息，能夠多個部署，相互獨立（比zookeeper輕量）;

　　　　　　Name Server 被設計成幾乎無狀態的，能夠橫向擴展，節點之間無任何信息同步；

　　　　　　每一個 Broker 與 Name Server 集羣中的全部節點創建長鏈接，定時註冊 Topic 在啓動的時候會到NameServer註冊；

　　　　　　Producer 與 Name Server 集羣中的其中一個節點（隨機選擇）創建長鏈接，按期從 Name Server 取 Topic 路由信息，並向提供 Topic 服務的 Master 創建長鏈接，且定時向 Master 發送心跳；

　　　　　   Consumer 與 Name Server 集羣中的其中一個節點（隨機選擇）創建長鏈接，按期從 Name Server 取 Topic 路由信息，並向提供 Topic 服務的 Master、 Slave 創建長鏈接，且定時向 Master、 Slave 發送心跳；

 

• RocketMQ 邏輯部署結構

　　　　　　　　　　

• Producer 與 Producer Group　　

　　　　　　Producer 表示消息隊列的生產者；

　　　　　　Producer Group 表示發送同類消息的多個 Producer 實例（一般爲發送一類消息，且發送邏輯一致），一個 Producer Group 下包含多個 Producer 實例，能夠是多臺機器，也能夠是一臺機器的多個進程，或者一個進程的多個 Producer 對象； 一個 Producer Group 能夠發送多個 Topic 消息；

　　　　　　Producer  Group  做用以下：

　　　　　　1. 標識一類 Producer

　　　　　　2. 能夠經過運維工具查詢這個發送消息應用下有多個 Producer 實例

　　　　　　3. 發送分佈式事務消息時，若是 Producer 中途意外宕機，Broker 會主動回調 Producer Group 內的任意一臺機器來確認事務狀態

 

• • Consumer 與 Consumer Group

 　　　　　　Consumer 表示消息隊列的消費者，Consumer 被分爲兩類：Push Consumer 和 Pull Consumer

• • • Push Consumer，Consumer 的一種，應用向 Consumer 對象註冊一個 Listener 接口，一旦收到消息，Consumer對象馬上回調 Listener 接口方法；
    • Pull Consumer，Consumer 的一種，應用一般主動調用 Consumer 的拉消息方法從 Broker 拉消息，主動權由應用控制；

　　　　　　Consumer Group 表示消費同類消息的多個實例（一般消費一類消息，且消費邏輯一致），一個 Consumer Group 下包含多個 Consumer 實例，能夠是多臺機器，也能夠是多個進程，或者是一個進程的多個 Consumer 對象，涉及的消費方式：廣播消費（BROADCASTING）和 集羣消費（默認 CLUSTERING）

• • • 廣播消費：一條消息被多個 Consumer 消費，即便這些 Consumer 屬於同一個 Consumer Group，消息也會被 Consumer Group 中的每一個 Consumer 都消費一次
    • 集羣消費：一個 Consumer Group 中的 Consumer 實例平均分攤消費消息，也就是說排除網絡等其餘緣由，一條消息只會被消費一次；大多數場景應該使用的是此種消費方式

 

• • Broker

　　　　　　Broker即爲消息隊列核心；它負責存儲消息、接收生產者產生的消息，爲消費者轉發消息。同時它還會存儲與消息相關的元數據，包括消費者組，消費進度偏移和主題/隊列信息；

 

• • Topic

　　　　　　主題，表示消息的第一級類型，標識一類消息的邏輯名字，好比一個電商系統能夠分爲：交易消息、物流消息等；Queue 是消息的物理管理單位，而 Topic 是消息的邏輯管理單位；一條消息必須有一個Topic；RocketMQ最佳實踐給出的建議是，一個應用盡量用一個Topic；一個 Topic 下能夠有多個 Queue，默認自動建立4個，手動建立8個；不管消息是生產仍是消費，都須要指定 Topic；

• • • Producer Group 和 Topic 消息之間的關係是多對多的關係　　　　　　　

 　　　　　　　　　一個 Producer Group 下的實例（Producer）能夠發送多個 Topic 的消息

  　　　　　　　　  一個 Topic 的消息也能夠由多個 Producer Group 下的實例（Producer）生產

• • •  Broker Group 和 Topic 消息之間的關係是多對多的關係

　　　　　　　　　一個 Broker Group 能夠爲多個 Topic 提供服務

    　　　　　　　　一個 Topic 能夠由一個或多個 Broker Group 提供服務

    　　　　　　　　一個 Topic 由多個 Broker Group 提供服務即《RocketMQ用戶指南》中提到的多 Master，或多 Master 多 Slave 模式

    　　　　　　　　一個 Topic 由一個 Broker Group 提供服務即《RocketMQ用戶指南》中提到的單 Master 模式（包含 Slave 或不包含 Slave）

• • •  Consumer Group 和 Topic 消息之間的關係是多對多的關係

 　　　　　　　　  一個  Consumer Group 下的實例 （Consumer）能夠消費多個 Topic 的消息

  　　　　　　　　 一個 Topic 的消息也能夠由多個 Consumer Group 下的實例（Consumer）消費

 

　　　　　　　Producer Group，Broker Group，Consumer Group，Topic 之間的關係

　　　　　　　　　　

 

　　　　　　　　

• • Tag　

　　　　　　標籤，表示消息的第二級（子主題）類型，對 Topic 的進一步細化，用於區分同一主題下不一樣的業務消息，好比交易消息又能夠分爲：交易建立消息、交易完成消息等，一條消息能夠沒有Tag；

 

• • Message Queue

　　　　　　消息隊列，簡稱 Queue 或 Q；消息物理管理單位；一個Topic下能夠設置多個 Queue；當發送消息時，須要執行該消息的 Topic，RocketMQ會輪詢該 Topic下的全部隊列，將消息發出去；一個 Topic 將有若干個 Q ；若 Topic 同時建立在不一樣的 Broker，則不一樣的 Broker上都有若干 Q，消息將物理地址存儲落在不一樣 Broker 結點上，具備水平擴展的能力；

　　　　　　不管生產者仍是消費者，實際的生產和消費都是針對 Q 級別；例如 Producer 發送消息的時候，會預先選擇（默認輪詢）好該 Topic 下面的某一條 Q 發送；Consumer 消費的時候也會負載均衡地分配若干個 Q，只拉取對應 Q 的消息；

　　　　　　每一條 Message Queue 均對應一個文件，這個文件存儲了實際消息的索引信息；即便文件被刪除，也能經過實際純粹的消息文件（commit log）恢復回來；

 

　　　　　　Broker，Topic，Queue 關係以下圖：

　　　　　　　　　　　　

• • 廣播消費

　　　　　　消費者的一種消費模式。消息將對一個 Consumer Group 下的各個Consumer實例都投遞一遍。即即便這些 Consumer 屬於同一個 Consumer Group，消息也會被 Consumer Group 中的每一個Consumer 都消費一次；

　　　　　　實際上，是一個消費組下的每一個消費者實例都獲取到了 Topic 下面的每一個 Message Queue 去拉取消費，消息會投遞到每一個消費者實例；

　　　　　　這種模式下，消費進度會存儲持久化到實例本地；

　　

• • 順序消費

　　　　　　消費消息的順序要同發送消息的順序一致；因爲 Consumer 消費消息的時候是針對 Message Queue 順序拉取並開始消費，且一條 Message Queue 只會給一個消費者（集羣模式下），因此可以保證同一個消費者實例對於 Q 上消息的消費是順序地開始消費（不必定順序消費完成，由於消費可能並行）；

　　　　　　在RocketMQ中，順序消費主要指的是都是Queue級別的局部順序。這一類消息爲知足順序性，必須Producer單線程順序發送，且發送到同一個隊列，這樣Consumer就能夠按照Producer發送的順序去消費消息；

　　　　　　生產者發送的時候能夠用 MessageQueueSelector 爲某一批消息（一般是有相同的惟一標示id）選擇同一個 Queue，則這一批消息的消費將是順序消息（並由同一個 Consumer 完成消息）。或者Message Queue 的數量只有1，但這樣消費的實例只能有一個，多出來的實例都會空跑。

 

• • 普通順序消費

　　　　　　順序消息的一種，正常狀況下能夠保證徹底的順序消息，可是一旦發生異常，Broker宕機或重啓，因爲隊列總數發生發化，消費者會觸發負載均衡，而默認地負載均衡算法採起哈希取模平均，這樣負載均衡分配到定位的隊列會發化，使得隊列可能分配到別的實例上，則會短暫地出現消息順序不一致；

　　　　　　若是業務能容忍在集羣異常狀況（如某個 Broker 宕機或者重啓）下，消息短暫的亂序，使用普通順序方式比較合適；

 

• • 嚴格順序消費

　　　　　　順序消息的一種，不管正常異常狀況都能保證順序，可是犧牲了分佈式 Failover 特性，即 Broker集羣中只要有一臺機器不可用，則整個集羣都不可用，服務可用性大大下降；

　　　　　　若是服務器部署爲同步雙寫模式，此缺陷可經過備機自動切換爲主避免，不過仍然會存在幾分鐘的服務不可用；（依賴同步雙寫，主備自動切換，自動切換功能目前並未實現）

　　　　　　 　　　　　　

 

 參考以下：

http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/

https://zhuanlan.zhihu.com/rocketmq

https://www.jianshu.com/p/453c6e7ff81c

《RocketMQ用戶指南》