服務端異常
地址沖突，在啟動broker時，出現地址已在使用錯誤
解決方案：修改配置文件里面的listenPort的值，然后重新啟動。
brokerName不匹配，啟動出現異常：broker-b does not match the expected group name: broker-a
問題原因：啟動其他Master broker服務時，直接將之前使用過的store目錄以及bdb目錄復制過來，僅僅只是修改了brokerName，導致此問題出現。
解決方案：2.0以后版本brokerName一旦創建啟動后就不能改變，否則只能刪除store目錄才能解決。
service not available
發送消息一定量的時候，出現 create maped file failed, please make sure OS and JDK both 64bit。或者當topic的隊列數位1024個的時候，會出現service not available now, maybe disk full，maybe your broker machine memory too small。
解決方案：使用ulimit-a命令查詢系統參數，檢查open files是否超過655350，max memory size是為否unlimited，若不是，需要重新根據安裝手冊的步驟，重新調整系統參數。
磁盤空間不足
當磁盤空間大于85%時，會出現“ CODE: 14 DESC: service not available now, maybe disk full, CL: 0.87 CQ: 0.87 INDEX: 0.87, maybe your broker machine memory too small.”的異常。
解決方案：消息中間件有兩種策略， 包括數據高安全性與服務高可靠性，分別如下：
| 策略 | 配置 | 說明 |
|---|---|---|
| 數據高安全性 | cleanFileForciblyEnable=false | 若磁盤使用率大于85%，有消息生產時或默認凌晨四點，則觸發刪除過期的消息，若沒過期消息則不會被刪除 |
| 服務高可靠性 | cleanFileForciblyEnable=true | 若磁盤使用率大于85%，有消息生產時或默認凌晨四點，則觸發刪除消息（在有效期內的數據將被刪除） |
若磁盤使用率大于85%，策略為數據高安全性，且無過期文件，可以按實際需求，減少數據保存時間來觸發消息刪除，騰出磁盤空間。
- 使用updateBrokerConfig命令，修改fileReservedTime屬性，此屬性為消息保存時間，單位為小時。按需減少保存時間，則可以騰出磁盤空間。
- 主備都需要同時修改。
通過deamon拉起broker時報錯
deamon.log日志中報Fail to queryBrokerMaxOffset。
問題原因：
- 配置文件錯誤。
- 做過主備切換，然后手動干預或重啟集群，啟動進程的地址和角色與zookeeper中存儲的不同，造成啟動失敗。
- 上次啟動失敗后未清理錯誤數據。
解決方法：
- 刪除zk中該集群的信息。
- 核對配置文件，確保端口和路徑有效。
刪除running目錄。
- 重新通過自動部署或者手動部署啟動進程。
消費進度停滯不前
通過consumerProgress命令查詢消費進度某些隊列無變化，而客戶端正在正常消費。
問題原因：某些隊列有消息沒有簽收，導致服務端消費進度沒有后移。
解決方案：通過consumerProgress命令顯示的consumer offset找到對應消息，并按如下判斷執行：
- 如果是BDB消費模式，重啟應用即可或者通過以下api void com.ctg.mq.api.IMQAckHandler.ackMessageSuccess(String msgID)簽收卡住的消息即可。
- 如果是原生有序消費模式，重啟應用即可。
- 如果是原生無序消費模式，啟動一個同消費組的實例，會將該消息簽收。
刪除topic失敗
刪除topic時出現topic **** is consuming by consumer ****，或者topic *** is publishing by producer ***異常。
問題原因：刪除topic必須沒有生產者和消費者正在訂閱該topic（與該topic相關的生產者消費者都必須離線），否則會失敗。
解決方案：
- 可以通過一下方式查看是否還有客戶端連接該topic：管理平臺->主題管理->詳情->生產組|消費組->連接實例。
- 如果使用命令行刪除有序隊列，需要使用集群刪除，例如：sh mqadmin deleteTopic -n 10.142.90.33:9876 -c mq_cluster -t mytesttopic。
- 如果使用命令行刪除無序隊列，可以使用broker刪除，例如：sh mqadmin deleteTopic -n 10.142.90.33:9876 -b 10.142.90.33:10911 -t mytesttopic。
啟動broker時BDB報錯
問題原因：可能是遷移了store目錄或者更換了broker的組名、地址或端口。
解決方案：刪除store目錄下的consumeStore目錄，重啟broker即可解決。
從broker已啟動，但clusterList看不到
從broker已啟動，但無法加入到集群（clusterList查詢不到）。
問題原因：
- 查看/etc/hosts文件，機器名與IP的映射關系是否填寫有誤。
- 查看防火墻設置（是否有端口未開放），listenPort 到 listenPort+2的端口都 需要開放（如果主broker的listenPort=10911，那么10911、10912、10913都要開放）。
通過命令行創建有序topic，但是web管理臺顯示的是無序的
通過updateTopic命令，加-o true創建有序topic，但是web端查詢的時候 顯示是無序的。
問題原因：集群有多個namesrv，但是創建的時候只填了一個namesrv。
解決方案：創建時加上這個broker集群的所有namesrv，中間用分號分割，例如：sh mqadmin updateTopic -n “10.142.90.30:9876;10.142.90.28:9876”-t crmTopic -o true。
消費者訂閱關系不存在
broker.log日志報錯：the consumer's subscription not exist, group: consumerAepIdealLogGroup。
問題原因：使用同個訂閱組，同時消費不同的topic，訂閱關系會被覆蓋。
解決方案：不能使用同個訂閱組的消費組去訂閱不同的topic，如果需要變換訂閱關系，請關閉舊消費者。
使用clusterList查詢 主TPS不為0，從TPS一直為0
這種情況最大的可能是從同步出錯，可以做進一步的確認，查看store.log或者 stoererror.log，一般會看到有持續的報錯信息。這種情況可以刪除從的store目錄，重新進行同步。
注意：部署有高可用模塊或者主的brokerRole=ASYNC_MASTER，否則停止從的時候，生產會報錯。
解決方案：
- 手工停止從broker（kill pid，注意不要加-9，如果自動拉起broker參數設置為true，則需要先關掉從的deamon）。
- 刪除或者備份從的store目錄（為保險起見，空間允許的話，可以mv備份，不要直接刪除。
- 手工啟動broker（sh sh/broker_*.sh）。
- 從broker啟動完成后，用clusterList查看，可以看到從的TPS比較高，因為正在同步。
主broker異常恢復
需要走異常恢復流程的一般是consumequeue生成有問題，導致無法拉取消息（注意 有多種情況會導致無法拉取消息，不一定是consumequeue有問題，注意判斷）、根據offset查詢報錯。
異常恢復流程：
1.停止需要恢復這一組broker的主從deamon，主從broker。
2.刪除主broker store目錄下的checkpoint consumequeue consumeStore index（也可以mv 改下名字來備份）。
3.檢查store目錄下的abort文存是否存在，如果不存在新建一個（touch abort）。
4.啟動主broker，查看store.log，可以看到打印恢復過程的日志，如果沒有報錯，說明恢復成功。
5.如果commitlog文件比較多，可能恢復時間較長，可以通過查看store.log或者broker端口是否起來判斷恢復是否完成。
6.主broker起來后，通過消費或者根據offset查詢消息來驗證是否恢復成功。
7.如果主broker恢復成功，啟動從broker，啟動主從deamon。
RPC異常（所以服務端組件均可能出現）
問題原因：使用非組件RPC協議訪問導致，比如用http協議、或者telnet等，均可導致decode錯誤。
解決方案：無需解決，應服務端及客戶端RPC請求均無影響。
應用客戶端
連接拒絕Connect faild
解決方案：當出現這類問題時，檢查當前網絡并無異常時，并排查下ulimit –a openfiles是否為1024，修改至65535。
超時異常RemotingTimeoutException
服務器端日志出現RemotingTimeoutException：wait response on the channel < 10.4.246.198:10911 > timeout, 3000ms。
解決方案：這類情況一般由于客戶端與服務端通信出現問題，可以ping Ip 以及telnet ip port 來排查這類，同時也要檢查防火墻的問題。
找不到路由No route info of this topic
問題可能原因：
- 沒創建topic。
- name server填錯了。
- 網絡問題無法獲取路由。
解決方案：
- 在管理臺創建topic。
- 檢查客戶端配置的namesrv的地址是否配錯了。
- 檢查網絡是否正常。
備不可用SLAVE_NOT_AVAILABLE
當生產者發送消息時，出現“status:SLAVE_NOT_AVAILABLE”，說明從節點發生狀況。
解決方案：
- 從節點機器出現問題，重啟從節點，并查看網絡連接。
- 在多網卡情況下，broker配置文件properties中，需增加配置項，例如：brokerIP1=10.4.246.130，brokerIP2=10.4.246.130
- 防止網卡ip讀取錯誤，取不到從節點信息。
消息體大小越界
客戶端報此類異常Fail to send message, for: message body size over max message size, max: 524288。
解決方案：
- 檢查服務端的最大消息體大小，即啟動broker配置文件的maxMessageSize大小，如未配置，默認是512K。
- 檢查客戶端設置的最大消息體(默認128k)是否小于當前發送的消息體大小。
注意：ROCKETMQ建議消息體在50K或以下(壓縮后)。
組名已經創建
當消息生產端/消費端運行時，報錯The producer/consumer group has been created。
問題原因：在同一個jvm里面只允許一個producerGroupName被加載一次 （consumerGroupName同理），否則就會報錯。
解決方案：
- 如果使用同一個producerGroupName，部署多個實例（起多個進程）。
- 在一個進程里，起多個線程，共用一個Producer對象實例。
Subscription group not exist或者拋出%retry%的topic沒有路由信息
問題原因：沒有建立消費關系或者沒有創建相關訂閱組。
解決方案：在管理臺或命令行創建對應訂閱組。
Messgae already acked，ackMessage failed
解決方案：這種異常表明該消息已被簽收，直接跳過即可。
重試簽收調用次數
ackMessageRetry重試簽收是只需要調一次就夠了，還是需要調多次。例如：簽收失敗后，調用重試簽收，如果重試簽收也失敗，是否需要再次調用重試簽收，還是會自動重試簽收。
現有版本接口不會自動幫你重試簽收的， 重試簽收失敗后，需要自己再次調用重試簽收接口。
簽收時出現不確定異常，如發生超時，或者網絡異常時，是需要應用判斷消息是否已經簽收成功
解決方案：
- 通過管理臺“即時查詢”模塊，查詢這消息是否已經簽收成功，看結果再做處理。
- 重試簽收，如果已經簽收會拋已簽收異常。主要還是看應用的自己處理。
客戶端注冊失敗
客戶端日志報No matched consumer for the PullRequest PullRequest。
問題原因：客戶端實例注冊失敗。
解決方案：檢查客戶端代碼，重啟客戶端進程。
the consumer message buffer is full, so do flow control
客戶端日志出現the consumer message buffer is full, so do flow control
問題原因：push客戶端消費過慢，本地緩存隊列已滿，暫時停止向服務端拉取消息。消費慢的原因可能是網絡原因、topic隊列數過多、消費者過少，內存過小等。
解決方案：
（1）查看網絡是否異常，緩慢。
（2）增加消費者實例。
（3）如果消息不重要，又不方便增加消費者實例，可以減少topic隊列數量。
system busy, start flow control for a while
客戶端日志出現 [REJECTREQUEST]system busy, start flow control for a while 或者 [PCBUSY_CLEAN_QUEUE]broker busy, start flow control for a while, period in queue。
問題原因：
- 在關閉生產者實例的同時用生產者實例發送消息，連接關閉了netty會拒絕請求。
- 線程少，處理發送請求過慢。
解決方案：
- 應用優化使用流程，禁止在close生產者實例后使用生產者。
- 如果Broker是同步主，那么改成異步主，或者將 sendMessageThreadPoolNums=32且waitTimeMillsInSendQueue=1000。
消費者消費不到消息如何處理
進入控制臺查看訂閱管理菜單，檢查訂閱組是否有消費實例在線，如果不在線檢查消費客戶端日志是否有連接異常。
檢查消費客戶端邏輯，是否存在訂閱關系不一致的情況。
消費者機器宕機重啟是否會造成消息丟失
RocketMQ的消息數據以及訂閱信息都是持久化保存的，當消費者下線重新上線后，會Broker持久化的下線前的消費偏移重新開始消費，所以不會發生消息丟失的情況。
訂閱消息時是否可以允許消息Tag為空
訂閱主題時如果Tag設置為空會導致消費者消費不到消息，如不希望通過Tag進行消息過濾，可以將Tag設置為*，示例如下：
consumer.subscribe(topic, "*");
客戶端連接時出現“signature validate by dauth failed”錯誤
這種錯誤的原因一般是由于ACL認證失敗，較大的可能是客戶端配置的AccessKey和SecretKey出現錯誤，可以檢查下這兩項配置是否輸入有誤。
