訊息佇列是分散式系統中重要的元件，使用訊息佇列主要是為了透過非同步處理提高系統性能和削峰、降低系統耦合性。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）
