RocketMQ 架構簡析
Apache RocketMQ 是阿里開源的一款高性能、高吞吐量的分布式消息中間件。
整體架構
-
路由元信息
-
topicQueueTable：topic 消息隊列路由信息。 -
brokerAddrTable：broker基礎信息。包含broker name，所屬集群名稱，主broker地址等。 -
clusterAddrTable：broker集群信息，存儲集群中所有broker的名稱。 -
brokerLiveTable：broker狀態信息。 -
filterServerTable：broker上的filterServer列表。filterServer用于消息過濾。
-
路由注冊? RocketMQ路由注冊是通過broker與Namesrv的心跳功能實現的。broker啟動時向集群中所有Namesrv發送心跳包，之后每隔30秒向集群中所有Namesrv發送心跳包。心跳包中包含：broker集群信息、broker信息、topic配置信息、broker關聯的FilterServer列表等。如果brokerA為Master。并且brokerA上的topic1的配置信息發生變化或初次注冊，Namesrv會根據報文創建或更新Topic路由元數據，填充topicQueueTable。 -
路由刪除? Namesrv收到brokerA的心跳包會更新brokerLiveTable中的brokerA對應的BrokerLiveInfo中的lastUpdateTimestamp。Namesrv每隔10秒掃描brokerLiveTable一次。如果brokerA對應的BrokerLiveInfo 中 lastUpdateTimestamp距當前時間超過 120秒，Namesrv認為brokerA失效，會將brokerA的路由信息移除并關閉與broker的socket連接。更新：topicQueueInfo、brokerAddrTable、brokerLiveTable、filterServerTable等。 -
路由發現? RocketMQ路由發現是非實時的。當Topic路由信息發生變化是，Namesrv不會主動推送給客戶端（Producer、Consumer）。而是由客戶端定時到Namesrv拉去最新的路由信息并緩存（包含Topic路由信息）。
與kafka對比
kafka 由zookeeper集群提供命名服務（Naming Service）。
Kafka通過 ZooKeeper 管理集群配置、選舉 Leader 以及在 consumer g
Broker
與kafka對比：
kafka和RocketMQ的broker都可以容納多個一個或多個分區數據（kafka分區：partition；RocketMQ分區：queue）。
kafka基于partition（分區） 做備份/高可用（partition follower）。
RocketMQ增加了broker group的概念，基于broker（可能包含多個分區）。
Producer、Consumer都只需要和集群中一個Namesrv建立長連接。Broker需要向集群中所有的Namesrv發送心跳包。
其實很好理解：
Namesrv集群提供高可用的命名服務。
Producer、Consumer只需要從其中一臺定期同步路由信息。
如果Broker只隨機調一臺發送心跳包。那么不同的Namesrv保存的路由信息會出現
消費者類型：
-
拉取式消費（Pull Consumer） Consumer消費的一種類型，應用通常主動調用Consumer的拉消息方法從Broker服務器拉消息、主動權由應用控制。一旦獲取了批量消息，應用就會啟動消費過程。Pull方式里，取消息的過程需要用戶自己寫（包括提交offset等操作）。 -
推動式消費（Push Consumer） Consumer消費的一種類型，該模式下Broker收到數據后會主動推送給消費端，該消費模式一般實時性較高。Push Consumer原理上也是采取pull模式。實際上就是長輪詢的pull模式。
一些概念
-
主題（Topic） 表示一類消息的集合，每個主題包含若干條消息，每條消息只能屬于一個主題，是RocketMQ進行消息訂閱的基本單位。每個topic可分為若干個分區（queue）。 -
生產者組（Producer Group） 同一類Producer的集合，這類Producer發送同一類消息且發送邏輯一致。如果發送的是事務消息且原始生產者在發送之后崩潰，則Broker服務器會聯系同一生產者組的其他生產者實例以提交或回溯消費。 -
消費者組（Consumer Group） 同一類Consumer的集合，這類Consumer通常消費同一類消息且消費邏輯一致。消費者組使得在消息消費方面，實現負載均衡和容錯的目標變得非常容易。要注意的是，消費者組的消費者實例必須訂閱完全相同的Topic。RocketMQ 支持兩種消息模式：集群消費（Clustering）和廣播消費（Broadcasting）。 -
普通順序消息（Normal Ordered Message） 普通順序消費模式下，消費者通過同一個消費隊列收到的消息是有順序的，不同消息隊列收到的消息則可能是無順序的。 -
嚴格順序消息（Strictly Ordered Message） 嚴格順序消息模式下，消費者收到的所有消息均是有順序的。 -
消息（Message） 消息系統所傳輸信息的物理載體，生產和消費數據的最小單位，每條消息必須屬于一個主題。RocketMQ中每個消息擁有唯一的Message ID，且可以攜帶具有業務標識的Key。系統提供了通過Message ID和Key查詢消息的功能。 -
標簽（Tag） 為消息設置的標志，用于同一主題下區分不同類型的消息。來自同一業務單元的消息，可以根據不同業務目的在同一主題下設置不同標簽。標簽能夠有效地保持代碼的清晰度和連貫性，并優化RocketMQ提供的查詢系統。消費者可以根據Tag實現對不同子主題的不同消費邏輯，實現更好的擴展性。
關于消息中間件
1. 消息優先級（Message Priority；RocketMQ不支持）
2. 順序消息（Message Order）
-
投遞消息的順序性：投遞消息的順序性可通過將一組消息投遞到同一分區實現。例如：借助MessageQueueSelector將對相同訂單的操作消息投放到同一分區。 -
消費消息的順序性：RoctetMQ特性保障：特定分區（queue）中的消息不能同時被同一個消費者組中的多個Consumer消費，以避免重復消費。通過自定義或使用預置的AllocateQueueStrategy可設定分區的分配策略（哪些分區分配給哪個消費者消費）。
3. 高可用、消息可靠性
3.1 消息持久化
3.2 broker master/salve
4. 高并發、可擴展 ==> 分布式
4.1 生產并行度
4.2 消費并行度
4.3 消息隊列分配策略
MessageQueueSelector
AllocateMessageQueueStrategy
AllocateMessageQueueAveragely：平均分配算法? AllocateMessageQueueAveragelyByCircle：基于環形平均分配算法 AllocateMachineRoomNearby：基于機房臨近原則算法 AllocateMessageQueueByMachineRoom：基于機房分配算法 AllocateMessageQueueConsistentHash：基于一致性hash算法 AllocateMessageQueueByConfig：基于配置分配算法
參考：
作者：RyanLee86799來源：https://juejin.im/post/6844904130822029320 文章轉載：JAVA高級架構
（版權歸原作者所有，侵刪）