背景

RocketMQ是阿里巴巴在2012年開發(fā)的分布式消息中間件，專為萬億級超大規(guī)模的消息處理而設(shè)計，具有高吞吐量、低延遲、海量堆積、順序收發(fā)等特點。

2015年，RocketMQ在消息傳遞方面迎來了一批重量級功能發(fā)布，包括事務(wù)消息、SQL過濾、軌跡追蹤、定時消息、高可用多活等，以滿足阿里巴巴日益豐富的業(yè)務(wù)場景。同年，RocketMQ被捐贈給Apache基金會，并入選孵化器項目，旨在未來為更多開發(fā)者服務(wù)。

2017年從Apache基金會畢業(yè)后，RocketMQ被指定為頂級項目（TLP）。

架構(gòu)模型

RocketMQ基于kafka的設(shè)計使用Java重寫，其架構(gòu)模型如下圖：

• NameServer Cluster 可以對應(yīng)Kafka中的Zookeeper Cluster。
• 多個Broker Master 可以對應(yīng)Kafka中的分區(qū)承載體。
• Broker Slave 可以對應(yīng)Kafka中的replica承載體。

NameServer 名字服務(wù)器

NameServer是一個簡單的 Topic 路由注冊中心，支持 Topic、Broker 的動態(tài)注冊與發(fā)現(xiàn)。主要包括兩個功能：

• Broker管理，NameServer接受Broker集群的注冊信息并且保存下來作為路由信息的基本數(shù)據(jù)。然后提供心跳檢測機制，檢查Broker是否還存活；
• 路由信息管理，每個NameServer將保存關(guān)于 Broker 集群的整個路由信息和用于客戶端查詢的隊列信息。Producer和Consumer通過NameServer就可以知道整個Broker集群的路由信息，從而進行消息的投遞和消費。

NameServer通常會有多個實例部署，各實例間相互不進行信息通訊。Broker是向每一臺NameServer注冊自己的路由信息，所以每一個NameServer實例上面都保存一份完整的路由信息。當某個NameServer因某種原因下線了，客戶端仍然可以向其它NameServer獲取路由信息。

Broker 代理服務(wù)器

Broker主要負責消息的存儲、投遞和查詢以及服務(wù)高可用保證。

在 Master-Slave 架構(gòu)中，Master可以部署多個，一個Master可以對應(yīng)多個Slave，但是一個Slave只能對應(yīng)一個Master。Master 與 Slave 的對應(yīng)關(guān)系通過指定相同的BrokerName，不同的BrokerId 來定義，BrokerId為0表示Master，非0表示Slave。

生產(chǎn)者

生產(chǎn)者用來構(gòu)建并傳輸消息到服務(wù)端的運行實體。生產(chǎn)者通常被集成在業(yè)務(wù)系統(tǒng)中，將業(yè)務(wù)消息按照要求封裝成消息并發(fā)送至服務(wù)端。投遞的過程支持快速失敗和重試，并且支持以下幾個形式：

• 普通消息
• 順序消息
• 事務(wù)消息
• 延遲消息
• 批量消息

主題

主題是消息傳輸和存儲的頂層容器，用于標識同一類業(yè)務(wù)邏輯的消息。 主題的作用主要如下：

• 定義數(shù)據(jù)的分類隔離： 建議將不同業(yè)務(wù)類型的數(shù)據(jù)拆分到不同的主題中管理，通過主題實現(xiàn)存儲的隔離性和訂閱隔離性。
• 定義數(shù)據(jù)的身份和權(quán)限：消息本身是匿名無身份的，同一分類的消息使用相同的主題來做身份識別和權(quán)限管理。

隊列

隊列是消息存儲和傳輸?shù)膶嶋H容器，也是消息的最小存儲單元。隊列的主要作用如下：

• 存儲順序性：隊列天然具備順序性，即消息按照進入隊列的順序?qū)懭氪鎯?，同一隊列間的消息天然存在順序關(guān)系，隊列頭部為最早寫入的消息，隊列尾部為最新寫入的消息。消息在隊列中的位置和消息之間的順序通過位點（Offset）進行標記管理。

消息

消息是最小數(shù)據(jù)傳輸單元。具備如下特點：

• 消息不可變性：消息本質(zhì)上是已經(jīng)產(chǎn)生并確定的事件，一旦產(chǎn)生后，消息的內(nèi)容不會發(fā)生改變。
• 消息持久化：RocketMQ 會默認對消息進行持久化，保證消息的可回溯性和系統(tǒng)故障場景下的可恢復(fù)性。

消息標簽

消息標簽是RocketMQ提供的細粒度消息分類屬性，可以在主題層級之下做消息類型的細分。

消息位點

消息是按到達RocketMQ服務(wù)端的先后順序存儲在指定主題的多個隊列中，每條消息在隊列中都有一個唯一的Long類型坐標，這個坐標被定義為消息位點。

消費者

消費者中用來接收并處理消息的運行實體。消費者通常被集成在業(yè)務(wù)系統(tǒng)中，從服務(wù)端獲取消息，并將消息轉(zhuǎn)化成業(yè)務(wù)可理解的信息，供業(yè)務(wù)邏輯處理。有以下幾個功能：

• 支持以推（push），拉（pull）兩種模式對消息進行消費。
• 支持集群方式和廣播方式的消費。

消費位點

一條消息被某個消費者消費完成后不會立即從隊列中刪除，RocketMQ會基于每個消費者分組記錄消費過的最新一條消息的位點，即消費位點?？梢酝ㄟ^重置消費位點來實現(xiàn)一些功能，比如，業(yè)務(wù)回溯，糾正處理。

消費者分組

消費者分組承載多個消費行為一致的消費者的負載均衡分組。和消費者不同，消費者分組并不是運行實體，而是一個邏輯資源，通過消費者分組初始化多個消費者實現(xiàn)消費性能的水平擴展以及高可用容災(zāi)。在消費者分組中，統(tǒng)一定義以下消費行為：

• 訂閱關(guān)系：消費者分組的粒度管理訂閱關(guān)系，實現(xiàn)訂閱關(guān)系的管理和追溯。
• 投遞順序性：服務(wù)端將消息投遞給消費者消費時，支持順序投遞和并發(fā)投遞，投遞方式在消費者分組中統(tǒng)一配置。
• 消費重試策略： 消費者消費消息失敗時的重試策略，包括重試次數(shù)、死信隊列設(shè)置等。具體信息，請參見消費重試。

訂閱關(guān)系

訂閱關(guān)系是RocketMQ系統(tǒng)中消費者獲取消息、處理消息的規(guī)則和狀態(tài)配置。

由消費者分組動態(tài)注冊到服務(wù)端系統(tǒng)，并在后續(xù)的消息傳輸中按照訂閱關(guān)系定義的過濾規(guī)則進行消息匹配和消費進度維護。通過配置訂閱關(guān)系，可控制如下傳輸行為：

• 消息過濾規(guī)則：用于控制消費者在消費消息時，選擇主題內(nèi)的哪些消息進行消費。
• 消費狀態(tài)：消費者分組在服務(wù)端注冊訂閱關(guān)系后，當消費者離線并再次上線后，可以獲取離線前的消費進度并繼續(xù)消費。

參考文章

RocketMQ官方文檔

到此這篇關(guān)于關(guān)于消息中間件RocketMQ的基本概念及功能的文章就介紹到這了,更多相關(guān)RocketMQ概念及功能內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論