28個SpringBoot項目中常用注解，日常開發、求職面試不再懵圈
前言在使用SpringBoot開發中或者在求職面試中都會使用到很多注解或者問到注解相關的知識。本文主要對一些常用的注解進行了總結，同時也會舉出具體例子，供大家學習和參考。注解
這篇文章，筆者想聊聊 RocketMQ 最佳實踐之一：保證訂閱關系一致。
訂閱關系一致指的是同一個消費者 Group ID 下所有 Consumer 實例所訂閱的 Topic 、Tag 必須完全一致。
如果訂閱關系不一致，消息消費的邏輯就會混亂，甚至導致消息丟失。
首先我們展示正確的訂閱關系：多個 Group ID 訂閱了多個 Topic，并且每個 Group ID 里的多個消費者的訂閱關系保持了一致。
正確的訂閱關系
接下來，我們展示錯誤的訂閱關系。
錯誤的訂閱關系
從上圖中，單個 Group ID 訂閱了多個 Topic，但是該 Group ID 里的多個消費者的訂閱關系并沒有保持一致。
代碼邏輯角度來看，每個消費者實例內訂閱方法的主題、 TAG、監聽邏輯都需要保持一致。
圖片
接下來，我們實驗相同消費組，兩種不正確的場景，看看消費者和 Broker 服務有什么異常。
訂閱主題不同，標簽相同
訂閱主題相同，標簽不同
圖片
當我們啟動兩個消費者后，消費者組名：myconsumerGroup。
C1消費者訂閱主題 TopicTest , C2消費者訂閱主題 mytest。
在 Broker 端的日志里，會不停的打印拉取消息失敗的日志 ：
2023-10-09 14:52:53 WARN PullMessageThread_2 - the consumer's subscription not exist, group: myconsumerGroup, topic:TopicTest那么在這種情況下，C1 消費者是不可能拉取到消息，也就不可能消費到最新的消息。
為什么呢 ？我們知道客戶端會定時的發送心跳包到 Broker 服務，心跳包中會包含消費者訂閱信息，數據格式樣例如下：
"subscriptionDataSet": [ { "classFilterMode": false, "codeSet": [], "expressionType": "TAG", "subString": "*", "subVersion": 1696832107020, "tagsSet": [], "topic": "TopicTest" }, { "classFilterMode": false, "codeSet": [], "expressionType": "TAG", "subString": "*", "subVersion": 1696832098221, "tagsSet": [], "topic": "%RETRY%myconsumerGroup" }]Broker 服務會調用 ClientManageProcessor 的 heartBeat方法處理心跳請求。
最終跟蹤到代碼：org.apache.rocketmq.broker.client.ConsumerManager#registerConsumer
圖片
Broker 服務的會保存消費者信息，消費者信息存儲在消費者表 consumerTable 。消費者表以消費組名為 key , 值為消費者組信息 ConsumerGroupInfo 。
#org.apache.rocketmq.broker.client.ConsumerManagerprivate final ConcurrentMap<String/* Group */, ConsumerGroupInfo> consumerTable = new ConcurrentHashMap<String, ConsumerGroupInfo>(1024);如果消費組的消費者信息 ConsumerGroupInfo 為空，則新建新的對象。
更新訂閱信息時，訂閱信息是按照消費組存放的，這步驟就會導致同一個消費組內的各個消費者客戶端的訂閱信息相互被覆蓋。
回到消費者客戶端，當消費者拉取消息時，Broker 服務會調用 PullMessageProcessor 的 processRequest 方法 。
首先會進行前置判斷，查詢當前的主題的訂閱信息若該主題的訂閱信息為空，則打印告警日志，并返回異常的響應結果。
subscriptionData = consumerGroupInfo.findSubscriptionData(requestHeader.getTopic()); if (null == subscriptionData) { log.warn("the consumer's subscription not exist, group: {}, topic:{}", requestHeader.getConsumerGroup(), response.setCode(ResponseCode.SUBSCRIPTION_NOT_EXIST); response.setRemark("the consumer's subscription not exist" + FAQUrl.suggestTodo(FAQUrl.SAME_GROUP_DIFFERENT_TOPIC)); return response;}通過調研 Broker 端的代碼，我們發現：相同消費組的訂閱信息必須保持一致 , 否則同一個消費組內的各個消費者客戶端的訂閱信息相互被覆蓋，從而導致某個消費者客戶端無法拉取到新的消息。
C1消費者無法消費主題 TopicTest 的消息數據，那么 C2 消費者訂閱主題 mytest，消費會正常嗎 ？
圖片
從上圖來看，依然有問題。主題 mytest 有四個隊列，但只有兩個隊列被分配了， 另外兩個隊列的消息就沒有辦法消費了。
要解釋這個問題，我們需要重新溫習負載均衡的原理。
負載均衡服務會根據消費模式為”廣播模式”還是“集群模式”做不同的邏輯處理，這里主要來看下集群模式下的主要處理流程：
(1) 獲取該主題下的消息消費隊列集合；
(2) 查詢 Broker 端獲取該消費組下消費者 Id 列表；
(3) 先對 Topic 下的消息消費隊列、消費者 Id 排序，然后用消息隊列分配策略算法（默認為：消息隊列的平均分配算法），計算出待拉取的消息隊列；
圖片
這里的平均分配算法，類似于分頁的算法，將所有 MessageQueue 排好序類似于記錄，將所有消費端排好序類似頁數，并求出每一頁需要包含的平均 size 和每個頁面記錄的范圍 range ，最后遍歷整個 range 而計算出當前消費端應該分配到的記錄。
(4) 分配到的消息隊列集合與 processQueueTable 做一個過濾比對操作。
圖片
消費者實例內 ，processQueueTable 對象存儲著當前負載均衡的隊列 ，以及該隊列的處理隊列 processQueue (消費快照)。
最后創建拉取消息請求列表，并將請求分發到消息拉取服務，進入拉取消息環節。
通過上面的介紹 ，通過負載均衡的原理推導，原因就顯而易見了。
圖片
C1消費者被分配了隊列 0、隊列 1 ，但是 C1消費者本身并沒有訂閱主題 mytest , 所以無法消費該主題的數據。
從本次實驗來看，C1消費者無法消費主題 TopicTest 的消息數據 , C2 消費者只能部分消費主題 mytest的消息數據。
但是因為在 Broker 端，同一個消費組內的各個消費者客戶端的訂閱信息相互被覆蓋，所以這種消費狀態非常混亂，偶爾也會切換成：C1消費者可以部分消費主題 TopicTest 的消息數據 , C2消費者無法消費主題 mytest的消息數據。
圖片
如圖，C1 消費者和 C2 消費者訂閱主題 TopicTest ，但兩者的標簽 TAG 并不相同。
啟動消費者服務之后，從控制臺觀察，負載均衡的效果也如預期一般正常。
圖片
筆者在 Broker 端打印埋點日志，發現主題 TopicTest 的訂閱信息為 ：
{ "classFilterMode": false, "codeSet": [66], "expressionType": "TAG", "subString": "B", "subVersion": 1696901014319, "tagsSet": ["B"], "topic": "TopicTest"}那么這種狀態，消費正常嗎 ？筆者做了一組實驗，消費依然混亂：
C1 消費者無法消費 TAG 值為 A 的消息 ，C2 消費者只能消費部分 TAG 值為 B 的消息。
想要理解原因，我們需要梳理消息過濾機制。
首先 ConsumeQueue 文件的格式如下 ：
圖片
我們模擬下消息過濾的過程：
圖片
首先，生產者將不同的消息發送到 Broker 端，不同的 TAG 的消息會發送到保存的不同的隊列中。
C1 消費者從隊列 0 ，隊列 1 中拉取消息時，因為 Broker 端該主題的訂閱信息中 TAG 值為 B ，經過服務端過濾后， C1 消費者拉取到的消息的 TAG 值都是 B , 但消費者在收到過濾的消息后，也需要進行客戶端過濾，A 并不等于 B ，所以 C1 消費者無法消費 TAG 值為 A 的消息。
C2 消費者從隊列 2， 隊列 3 中拉取消息，整個邏輯鏈路是正常的 ，但是因為負載均衡的緣故，它無法消費隊列 0 ，隊列 1的消息。
什么是消費組 ？消費同一類消息且消費邏輯一致 。
RocketMQ 4.X 源碼實現就是為了和消費組的定義保持一致 ，假如訂閱關系不一致，那么代碼執行邏輯就會出現混亂。
規避訂閱關系不一致這個問題有兩種方式 :
最后的思考：
假如從基礎架構層面來思考，將訂閱關系信息中心化來設計，應該也可以實現 ，但成本較高，對于中小企業來講，并不合算。
參考資料：
RocketMQ為什么要保證訂閱關系的一致性
https://cloud.tencent.com/developer/article/1474885
RocketMQ最佳實踐之坑？
https://mp.weixin.qq.com/s/Ypk-U8uVu4aZKMinbfU3xQ
源碼分析RocketMQ消息過濾機制
https://blog.csdn/prestigeding/article/details/79255328
本文鏈接：http://www.tebozhan.com/showinfo-26-13584-0.html兩個實驗讓我徹底弄懂了「訂閱關系一致」
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號