1: consumer會每30s從nameserver上更新所訂閱的topic路由列表,同時會更新broker路由->brokerName與角色和地址關係
2: consumer會每30s與所有broker進行一次心跳,將clientid,topic,group發送至broker
rebalance開始: consumer會每10s進行一次rebalance
1 首先選擇一個broker,根據topic和group查詢到訂閱此topic的屬於同一group的所有的consumer clientid
2 根據rebalance策略,進行分配.rebalance完畢之後,就可以知道當前的consumer消費哪些broker的哪些queue
重點在步驟4和5.1和5.2，現在只針對一個broker做一下分析：
假設consumer1先啓動，對於broker_a一開始關係是group1->topic1
當consumer2啓動並rebalance完成後，consumer2發送group1->topic2,
在步驟4，會根據group1將原先的group1->topic1取出。
在步驟5.1，添加topic2
在步驟5.2，移除topic1
這個對應關係呢,對應着一個重要的對象,如下圖,對於上面rebalance之後的結果會產生8個PullRequest對象,分別對應8個隊列:
PullMessageService爲一個阻塞隊列服務,其內有一個線程不斷輪詢隊列,獲取PullRequest對象,調用DefaultMQPushConsumerImpl進行消息拉取
DefaultMQPushConsumerImpl消息拉取前進行狀態,參數校驗和準備,並負責構造回調實例PullCallback進行消息的消費. 調用PullAPIWrapper進行消息拉取
PullAPIWrapper主要負責broker路由的解析,壓力均衡
NettyRemotingClient爲netty封裝,負責與broker通信,並在結果返回後回調PullCallback
PullCallback對返回的結果進行解碼,更新下次拉取的偏移量,並調用ConsumeMessageService觸發客戶端消費,它還會將PullRequest放回PullMessageService,從而形成一個循環.
ConsumeMessageService負責調用客戶端的併發消費或順序消費,並處理消費的結果.
對於廣播模式,消費失敗的消息不作處理
對於集羣模式,消費失敗的發到重試隊列,發送失敗的嘗試讓客戶端繼續消費
對於集羣模式,消費失敗的消息且重試次數>16,則發往DLQ,表示該消息不再重試,爲死消息.
rebalance中,如果topic路由發生變化,會新生成PullRequest,其中的屬性netxOffset採用用戶設置的ConsumeFromWhere,計算響應的偏移量.
-
首先說下集羣消費模式下的offset請求:
-
![]()
-
針對返回的offset>=0的情況,三種消費位置都直接接受,即從offset處消費
只有對於offset<0的情況(即這個topic的queue沒有被此group消費過,或者說這個group第一次啓動)不一樣:
CONSUME_FROM_LAST_OFFSET: 會繼續拉取隊列的最大偏移量作爲消費的起始位置
CONSUME_FROM_FIRST_OFFSET: 消費的起始位置爲0
CONSUME_FROM_TIMESTAMP: 首先根據時間戳定位到consumerqueue的位置文件上,通過二分查找法遍歷commitlog中的消息的時間戳,查找起始位置
廣播模式與集羣模式類似,唯一不同的是不會從broker查詢,而是從本地文件查詢offset
原文鏈接：https://blog.csdn.net/a417930422/article/details/50663639
