1. 收不到消息-consumerOffset.json 信息錯位
這種情況一般是，手動刪除了store/commitlog目錄里的數據等非常規手段造成了consumerOffset.json中記錄的還是原來的信息，導致consumer收不到消息。
rocketmq的broker，一個消息主題對應多個隊列，這些隊列的消費進度會記錄在consumerOffset.json文件中。所以一旦這個文件中記錄的還是老的offset信息，那么既然就消費不到消息。
一個主題對應幾個隊列，是記錄在$home/store/config/topics.json中的。
topics.json同事發現 如果是自動創建topic，則此處值默認是4，對應broker配置文件的defaultTopicQueueNums項目。如果是手動創建，此處值是8。
注意上面這個文件的路徑，目前分析來看，即使你在broker的配置文件中指定了storePathRootDir在其他路徑，但是topics.json的信息還是在上面讀取。因為這個定制配置信息是后加載的。(rocketmq版本 3.5.8)
這種問題處理辦法，如果不是生產環境，可以停掉broker然后把store目錄刪除，重啟broker。
此處收不到 消息沒有任何報錯。
2. 收不到消息-subscription group not exist
這種情況是在broker的配置文件中設置了autoCreateSubscriptionGroup項為false(默認這一項值true)。
解決辦法：要么將上述配置項修改成true。要么用命令行創建訂閱組。
sh mqadmin updateSubGroup -g test_group -n localhost:9876 -b localhost:10911
注意：這種情況 在pull形式消費時會報錯，在push形式消費時沒有任何錯誤。
錯誤異常代碼：
response.setCode(ResponseCode.SUBSCRIPTION_GROUP_NOT_EXIST);
response.setRemark("subscription group not exist, " + requestHeader.getConsumerGroup() + " "
+ FAQUrl.suggestTodo(FAQUrl.SUBSCRIPTION_GROUP_NOT_EXIST));
3. 收不到消息-一般需要定位哪些代碼
正常來講，分為兩個方面，一是看producer端發送消息有沒有成功，而是看consumer端有沒有拿到消息
1. producer端定位broker服務的
com.alibaba.rocketmq.store.CommitLog.putMessage(MessageExtBrokerInner)
看看這個方法的返回的result是不是成功的即可。
詳細分析參見我之前寫的 rocketmq源碼分析2-broker的消息接收
2. consumer端定位broker服務的
com.alibaba.rocketmq.broker.processor.PullMessageProcessor.processRequest(Channel, RemotingCommand, boolean)
看看能不能走到方法體中的case found分支即可。
詳細分析參見我之前寫的 rocketmq源碼分析3-consumer消息獲取
4. 消費完的消息 哪去了
我們在消費完消息后，如果是push的形式 我們會回一個success的狀態，如果是pull的形式我們會更新offset。此處可以看到，消費完之后，更新的消息消費的offset，以使mq不會再定時push給你。
那么消費完的消息在broker上還在不在？答案是在的，硬盤上有存儲。因為我們可以通過根據消息id查看的消息的方式找到消息。
MessageExt viewMessage = consumer.viewMessage("0A00007400002A9F0000000000010C5E");
當然，rocketmq允許你配置，消息留存多長時間，以及每天幾點清除。
--EOF--