RocketMQ-初体验RocketMQ(05)_RocketMQ架构解读
文章目錄
- Rocketmq整體架構
- namesrv
- broker
- producer & consumer
- 通信方式
Rocketmq整體架構
RocketMQ-初體驗RocketMQ(01)_RocketMQ初體驗中 對 RocketMQ 架構圖做了一個大體的介紹
接下來，我們再細說一下RocketMQ的架構
如上圖
整體由4部分組成
- namesrv
- broker
- producer
- consumer
namesrv
當broker服務啟動后，會向namesrv注冊信息，比如broker中的 主題、消費偏移量、隊列、ip、端口等，由broker的心跳發送到namesrv。
broker cluster中的每一個節點都會注冊到namesrv上。
比如 你有4個broker節點，2個namesrv，那么注冊如下
這種情況的話，即使一個namesrv節點掛了，剩下的一個namesrv節點仍然包含所有的broker信息。
需要注意的是： namesrv是無狀態的， namesrv之間不會相互通信，跟zk是不一樣的。一個namesrv掛了，不會影響另外一個namesrv，這倆namesrv是沒有關聯的。
broker
來南下每個broker的組成吧
每一個broker節點 ，儲存消息，都會對應一個commitlog , commitlog 負責存儲真實的消息的內容。
broker中的每個topic , 如果不設置的話， 默認創建4個隊列， 隊列編號 0 ， 1 ，2 ， 3. 每個隊列都會對應一個持久化文件 。
當producer向broker中的topic發送消息的時候， 如果發現隊列沒有創建持久化文件，會自動創建。 然后該隊列的持久化信息都會存放在該持久化文件中。
每個broker下面會創建一個consumerOffset.json文件. 這個json文件用來記錄當前你消費節點已經消費的數據位置，即消費的偏移量。這個也是需要持久化的。 這個偏移量的來源 是 consumer 來上報的。（如下圖）
consumer從broker中拉取消息后，要進行消費，消費了多多少消息，要把消費這些對應的這些偏移量上報到broker上去。 主要是為了什么呢？ ---->最大可能的避免消息重復的推送。
producer & consumer
Q: producer & consumer 到底選擇跟哪個broker去連接，去消費哪個broker中的消息？
A: producer & consumer也是無狀態的，每一個producer之間 ，每一個consumer之間都不會通信， 每個producer和consumer內部都有自己的一套負載均衡的算法 ，默認的選擇策略： 已發送的消息數量對queuecount取mod .
消費者的兩種消費模式主要有兩種： 推跟拉
-
拉取式消費（Pull Consumer）：Consumer消費的一種類型，應用通常主動調用Consumer的拉消息方法從Broker服務器拉消息、主動權由應用控制。一旦獲取了批量消息，應用就會啟動消費過程。
-
推動式消費（Push Consumer）：Consumer消費的一種類型，該模式下Broker收到數據后會主動推送給消費端，該消費模式一般實時性較高。
pull的方式，由客戶端來主動獲取，通過定時任務或者需要的時候從broker端獲取，這種方式用的比較少。 如果消息量比較少， 堆積也不會太多，對安全性要求不高的應用，可以考慮。
與此對應的另外一種push方式：
push的方式，在RocketMQ中其實也是基于pull模式的一個深度封裝，consumer對broker進行一個長輪詢，一直監聽broker中的數據，就好像是broker主動推送給consumer似的。
通信方式
producer/consumer broker namesrv 通信方式
producer/consumer 給 broker發送消息/消費消息，或者從 namesrv拉取消息 ， 通信是基于netty的方式，優先選用epoll方式，如果操作系統不支持epoll的話，會選擇NIO。
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀
總結
以上是生活随笔為你收集整理的RocketMQ-初体验RocketMQ(05)_RocketMQ架构解读的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： RocketMQ-初体验RocketMQ
- 下一篇： RocketMQ-初体验RocketMQ