RocketMQ介紹

 消息隊列是分佈式系統中重要的組件，使用消息隊列主要是爲了經過異步處理提升系統性能和削峯、下降系統耦合性。Apache RocketMQ是由阿里巴巴開源的可支撐萬億級數據洪峯的分佈式消息和流計算平臺，於2016年捐贈給Apache Software Foundation，2017年9月25日成爲Apache 頂級項目。因爲其高穩定性、低延時、高吞吐量等特色，被大規模應用於金融、互聯網、物流公司的核心交易支付、實時位置追蹤、大數據分析等場景，同時也被電力、交通、汽車、零售等十幾個行業的數萬家企業普遍使用，是企業數字化轉型的核心基礎性軟件。​

 網上對RocketMQ的介紹不少，還有中文開發者網站http://rocketmq.cloud/zh-cn/index.html，你們能夠自行搜索。本章結合網上的各類介紹（內容均來自網上），只對相關的內容、概念進行說明，爲後續文章作準備。

 工做中也比較多的接觸RocketMQ，以前看過RocketMQ的源碼，梳理過流程，可是沒有輸出文檔。爲此，這邊將以RocketMQ 4.4.0版本爲例，從新整理源碼中相應的流程。

1. 整體架構

 以下爲RocketMQ的整體架構：

這裏涉及到的角色包括：

• NameServer:NameServer是一個很是簡單的Topic路由註冊中心，其角色相似Dubbo中的zookeeper，支持Broker的動態註冊與發現。主要包括兩個功能：

  • Broker管理，NameServer接受Broker集羣的註冊信息而且保存下來做爲路由信息的基本數據。而後提供心跳檢測機制，檢查Broker是否還存活
  • 路由信息管理，每一個NameServer將保存關於Broker集羣的整個路由信息和用於客戶端查詢的隊列信息。而後Producer和Conumser經過NameServer就能夠知道整個Broker集羣的路由信息，從而進行消息的投遞和消費。

NameServer一般也是集羣的方式部署，各實例間相互不進行信息通信。Broker是向每一臺NameServer註冊本身的路由信息，因此每個NameServer實例上面都保存一份完整的路由信息。當某個NameServer因某種緣由下線了，Broker仍然能夠向其它NameServer同步其路由信息，Producer,Consumer仍然能夠動態感知Broker的路由的信息。

• Broker:Broker主要負責消息的存儲、投遞和查詢以及服務高可用保證。Broker部署相對複雜，Broker分爲Master與Slave，一個Master能夠對應多個Slave，可是一個Slave只能對應一個Master，Master與Slave 的對應關係經過指定相同的BrokerName，不一樣的BrokerId 來定義，BrokerId爲0表示Master，非0表示Slave。Master也能夠部署多個。每一個Broker與NameServer集羣中的全部節點創建長鏈接，定時註冊Topic信息到全部NameServer。

• Producer:消息發佈的角色，支持分佈式集羣方式部署。

  • Producer經過MQ的負載均衡模塊選擇相應的Broker集羣隊列進行消息投遞，投遞的過程支持快速失敗而且低延遲。
  • Producer與NameServer集羣中的其中一個節點（隨機選擇）創建長鏈接，按期從NameServer獲取Topic路由信息，並向提供Topic 服務的Master創建長鏈接，且定時向Master發送心跳。Producer徹底無狀態，可集羣部署。
• Producer Group:一類 Producer 的集合名稱，這類 Producer 一般發送一類消息，且消費邏輯一致。

• Consumer:消息消費的角色，支持分佈式集羣方式部署。支持以push推，pull拉兩種模式對消息進行消費。同時也支持集羣方式和廣播方式的消費，它提供實時消息訂閱機制，能夠知足大多數用戶的需求。

  • Consumer既能夠從Master訂閱消息，也能夠從Slave訂閱消息，消費者在向Master拉取消息時，Master服務器會根據拉取偏移量與最大偏移量的距離（判斷是否讀老消息，產生讀I/O），以及從服務器是否可讀等因素建議下一次是從Master仍是Slave拉取。
  • Consumer與NameServer集羣中的其中一個節點（隨機選擇）創建長鏈接，按期從NameServer獲取Topic路由信息，並向提供Topic服務的Master、Slave創建長鏈接，且定時向Master、Slave發送心跳。
• Consumer Group:一類 Consumer 的集合名稱，這類 Consumer 一般消費一類消息，且消費邏輯一致。

2. 工做流程

結合部署架構圖，描述集羣工做流程：

• 啓動NameServer，NameServer起來後監聽端口，等待Broker、Producer、Consumer連上來，至關於一個路由控制中心。
• Broker啓動，跟全部的NameServer保持長鏈接，定時發送心跳包。心跳包中包含當前Broker信息(IP+端口等)以及存儲全部Topic信息。註冊成功後，NameServer集羣中就有Topic跟Broker的映射關係。
• 收發消息前，先建立Topic，建立Topic時須要指定該Topic要存儲在哪些Broker上，也能夠在發送消息時自動建立Topic。
• Producer發送消息，啓動時先跟NameServer集羣中的其中一臺創建長鏈接，並從NameServer中獲取當前發送的Topic存在哪些Broker上，輪詢從隊列列表中選擇一個隊列，而後與隊列所在的Broker創建長鏈接從而向Broker發消息。
• Consumer跟Producer相似，跟其中一臺NameServer創建長鏈接，獲取當前訂閱Topic存在哪些Broker上，而後直接跟Broker創建鏈接通道，開始消費消息。

 以下圖示：

 Producer會向一些隊列輪流發送消息，這些隊列集合稱爲Topic。Consumer能夠作廣播消費，也能夠作集羣消費，若是作廣播消費，則一個Consumer實例消費這個Topic對應的全部隊列，若是作集羣消費，則多個Consumer 實例平均消費這個Topic對應的隊列集合。

 Topic是邏輯概念，對於RocketMQ，一個Topic能夠分佈在各個Broker上，把一個Topic分佈在一個Broker上的子集定義爲一個Topic分片，其實就是在某一broke上一個topic的部分數據

對應上圖，TopicA有3個Topic分片，分佈在Broker1,Broker2和Broker3上，TopicB有2個Topic分片，分佈在Broker1和Broker2上，TopicC有2個Topic分片，分佈在Broker2和Broker3上。

 將Topic分片再切分爲若干等分，其中的一份就是一個Queue（隊列）。每一個Topic分片等分的Queue的數量能夠不一樣，由用戶在建立Topic時指定。每一個Topic分片等分的Queue的數量能夠不一樣，由用戶在建立Topic時指定, 是消費負載均衡過程當中資源分配的基本單元。須要指出的是，在一個Consumer Group內，Queue和Consumer之間的對應關係是一對多的關係：一個Queue最多隻能分配給一個Consumer，一個Cosumer能夠分配獲得多個Queue。這樣的分配規則，每一個Queue只有一個消費者，能夠避免消費過程當中的多線程處理和資源鎖定，有效提升各Consumer消費的並行度和處理效率。便是負載均衡過程當中資源分配的基本單元，同Kafaka相同。

3. 消息

 消息(Message)是系統所傳輸信息的物理載體，生產和消費數據的最小單位，每條消息必須屬於一個Topic。RocketMQ中每一個消息擁有惟一的Message ID，且能夠攜帶具備業務標識的Key。系統提供了經過Message ID和Key查詢消息的功能。

 能夠爲消息設置標誌（Tag），用於同一Topic下區分不一樣類型的消息。來自同一業務單元的消息，能夠根據不一樣業務目的在同一Topic下設置不一樣標籤。標籤可以有效地保持代碼的清晰度和連貫性，並優化RocketMQ提供的查詢系統。消費者能夠根據Tag實現對不一樣子主題的不一樣消費邏輯，實現更好的擴展性。

 消息的消費能夠分爲集羣消費和廣播消費

• 集羣消費（Clustering）：集羣消費模式下,相同Consumer Group的每一個Consumer實例平均分攤消息。
• 廣播消費（Broadcasting）：廣播消費模式下，相同Consumer Group的每一個Consumer實例都接收全量的消息。

更多原創內容請搜索微信公衆號：啊駝（doubaotaizi）