上一章： 消費問題排查 | 《Rocket MQ 使用排查指南》第三章>>> 點選免費下載下傳 《Rocket MQ 使用排查指南》>>>
控制台相關問題
【執行個體詳情】--【資料統計】消息堆積top
【問題描述】：
在【執行個體詳情】--【資料統計】當中看到某個group有堆積，實際上【group管理】--【消費者狀态】當中檢視這個group并沒有堆積
【問題原因】：
執行個體詳情--資料統計當中的消息堆積量是有一定延遲的，是采樣資料，不是實時資料，服務消費者狀态始終是離線，也看不到訂閱關系，導緻消息一直沒法消費可能會是之前的曆史資料，具體的還是要以group管理當中的實時消息堆積量為準
為什麼執行個體下沒有該topic，建立的時候卻提示該topic已存在
建立topic的時候，該執行個體下不存在建立的topic，建立的時候卻提示該topic已存在
沒有命名空間的執行個體下的topic我們是要求全局唯一的，也就是說這個topic名稱在全阿裡都是要求全局唯一的。這個topic名稱應該是已經被其他的使用者使用過了
可以在【執行個體詳情】--【執行個體資訊】當中檢視該執行個體是否有命名空間
查詢出來的消息，顯示的消費者超過實際的消費者
這個topic隻有一個消費者在消費，但是實際上查出來可以進行消費驗證的消費者卻不止目前有訂閱關系的消費者
【問題回答】：
如果這個gid曾經訂閱過這個topic(現在不訂閱了)/現在正在訂閱這個topic，并且在控制台的group管理可以查得到這個gid，那麼查詢消息的時候就會顯示在可以進行消費驗證的地方
如果您這個gid已經在控制台被删除了，那麼查詢的時候，就不會再看到有這個gid了。
消費者狀态連接配接資訊的用戶端ID，公網IP是什麼？
【問題描述】；
1、 用戶端id就是擷取的本機真實ip，linux環境下利用 ifconfig 檢視，windows環境利用ipconfig檢視,使用的是NetworkInterface.getNetworkInterfaces() 擷取的
2、公網ip可以了解為代理ip，有了這個ip才可以上網。linux環境可以利用 curl ifconfig.me 或 curl cip.cc檢視，windows環境直接百度搜尋ip檢視
資源報表當中采集類型的tps是什麼意思
是TransactionsPerSecond的縮寫，也就是每秒處理的事務數。MQ中主要用來表示 某個topic的每秒鐘生産了多少消息數量或某個消費組每秒消費了多少消息數量。
為什麼控制台檢視不到pid了
為什麼代碼當中的pid現在在控制台檢視不到了
1、RokcetMQ現在已經沒有pid的概念了，是以原先代碼當中填入的pid都是無法查詢到的。
2、如果不想代碼當中有messageProducerId配置，建議将sdk更新到最新版本，參照文檔當中的最新代碼的寫法，修改代碼。
不建議直接将pid改成gid。因為現在的最新的消息生産者當中隻需要填寫發送消息的topic，不需要填寫pid和gid了
需要注意的是新版本的sdk是相容舊版本的，
雖然都是相容的，切換版本後，也請做好線下測試，再線上灰階釋出
如果後續建立執行個體，有命名空間的，接入點配置項需要變化，代碼中的 ONSAddr 需要修改為 NAMESRV_ADDR。
有命名空間的執行個體，每個執行個體的接入點不同，在控制台“執行個體管理”頁面可以看到接入點位址
消費者狀态當中的消息延遲時間是如何計算的
消息延遲時間的計算公式： 延遲時間 = 未消費消息在隊列中的最大時間 = 目前時間 - 最開始堆積的那條消息的時間
告警監控相關問題
收到告警，但是控制台卻檢視不到報警規則
接到了監控告警消息，但是在控制台檢視該監控告警的規則，卻沒有看到
Mq的監控報警隻能有建立該監控報警的賬号登陸才能檢視，主賬号以及其他賬号不能檢視監控。
是以如果自己的賬号檢視不到該告警，那麼表明是其他賬号設定了報警
設定了報警，沒有收到報警短信
為什麼設定了報警，檢視資源也的确符合報警的規則，但是卻沒有收到報警的短信通知
【排查步驟】：
1.首先确認執行個體所在地域（Region）支援監控報警功能
2.确認設定的報警接收人的手機号碼為中國大陸地區的手機号
3.确認目前消費者是否線上，報警必須要目前消費者線上才可以
資源包費用相關問題
Api計費标準
Api是如何計費的
API 請求次數 = 發送消息 API 請求次數 + 訂閱消息 API 請求次數 + 長輪詢 API 請求次數；
以普通消息為例，發一條消息調用api和消費該條消息 算是調用了兩次api
長輪詢就是說針對每一個隊列（queue），消費端會每15秒拉取一次消息，看看topic當中是否有可見的需要消費的消息。每一次拉取都算是一次調用api，都會收取費用。
是以一個topic下面如有有3個broker，每個broker有8個隊列，如果該topic當中一整天都沒有消息進來，那麼一天就是242460*4次調用。是以建議如果消費消息不多，可以隔一段時間重新開機一下消費段。
長輪詢是建立在消費端線上的狀态下。
隊列queue個數是本身執行個體決定的，這個目前不支援使用者側配置Topic底層對應的queue數目。并且不支援修改queue的個數
标準版執行個體tps用量限制
标準版執行個體的tps使用限制是多少
單執行個體收發TPS限制5000條/秒，單個執行個體的使用限制是保證tps最大到5000是一定有的，但是實際會超過5000，超過的性能不保障。
但是鉑金版執行個體的tps是可以在購買的時候定制的，如果想要更加高的tps建議直接購買鉑金版，因為如果在标準版執行個體的基礎上申請調大tps，可能花費的金額會比直接購買鉑金版執行個體還要高
計費常見問題
【問題描述及回答】：
1、
問：每天扣除 2 元，這是什麼費用？
答：消息隊列 RocketMQ 版費用 = API 調用費 + Topic 資源占用費。每個 Topic 資源占用費為 2 元/天。
2、
問：我昨天删除了 Topic，為什麼今天會收到賬單并被扣費？
答：Topic 資源占用費以每天 00:00-23:59:59 為周期進行計費，第二天收費。是以，昨天删除 Topic，昨天的計費系統已經計入，今天會出賬單進行扣費，明天就不會出賬單扣費。
3、
問：我沒有使用消息隊列 RocketMQ 版服務，為什麼會扣費？
答：請檢視賬單，檢查您是否有使用消息隊列 RocketMQ 版服務
如果您不需要使用消息隊列 RocketMQ 版服務，請及時删除消息隊列 RocketMQ 版控制台上所有資源，避免不必要的支出
4、
問：我有看到消息隊列 RocketMQ 版的扣費，但是我在控制台上看到沒有開通消息隊列 RocketMQ 版？
答：消息隊列 RocketMQ 版處于欠費狀态超過 72 小時，阿裡雲将暫停為您提供服務，即您不能再通路消息隊列 RocketMQ 版控制台與消息隊列 RocketMQ 版 API。但是您的消息隊列 RocketMQ 版服務被釋放之前的欠費仍然需要結清。
5、
問：如何關閉消息隊列 RocketMQ 版服務？
答：請删除所有地域 Topic 資源，并将所有發送端，消費端停止。
6、
問：一天的消息總量為 631,238 條，但是通過費用查詢結果：API 調用次數為 126,315,056 次，那麼多 API 調用次數怎麼來的？
答：API 調用次數 = 發送消息 API 調用次數 + 訂閱消息 API 調用次數 + 長輪詢 API 調用次數（長輪詢說明：消息隊列 RocketMQ 版 Consumer 為保證消息實時推送而産生的 API 調用，每個隊列 15 秒一次長輪詢，在此期間，若隊列内有消息産生，則不計長輪詢次數）。
如何檢視整個執行個體的tps以及總存儲用量
如何如何檢視整個執行個體的tps以及該執行個體的總存儲用量
整個執行個體的總tps：
取資源報表裡每個topic一天當中高峰期tps最大值，然後加起來，就可以算出來總的tps
如果您要在該執行個體下添加新的topic，原來的topic上配置設定的tps會分流一部分到新建立的topic上面（如果執行個體下原有的所有topic的tps總和已經快達到上限）
就是說原來的topic的tps可能會降低一些，然後會分流給到新建立的topic
消息存儲空間 也是有計算公式的：每個topic下每天發送的總量 相加 再乘以每條消息的位元組數 就可以算出一天的大小
而且broker磁盤使用率超過總量的80%，就會去删除過期的消息，不會存在磁盤不夠用的情況（過期消息：已經消費過的還沒有被删除的消息）
在原有執行個體上更新成鉑金版，支付後卻多出一個新的執行個體？
在原有的标準版執行個體上直接點選鉑金版更新，完成訂單支付後，原有執行個體沒有變成鉑金版執行個體，但是卻新增多出一個鉑金版執行個體
由于之前很多使用者是不想把标準版上的所有資源都更新到鉑金版，是以目前是調整為更新鉑金版預設生成一個新的執行個體。
客戶側把确認需要資源遷移到鉑金版之後，再決定是否保留原來的标準版執行個體。
如果需要鉑金版執行個體的接入點還是和原有執行個體的接入點保持一緻，後端會将接入點同步成原來的
日志相關問題
更新c++版本到2.0後，日志占用磁盤問題
c++的sdk更新到2.0後日志過多，甚至導緻開發環境磁盤100%，這個怎麼限制日志大小
【問題答案】：
C++的tcp的sdk内置的是java的日志，目前這個日志過多，建議寫個日志切割腳本，定時執行日志切割删除，目前服務端沒有對日志進行定時切割和删除的動作
Ons.log用戶端日志說明
【異常描述及說明】：
列印資訊：
[persistAll] Group: CID_XXXX ClientId: 10.31.40.100@171374#14159488#-2036649484#20931314294957812 updateConsumeOffsetToBroker MessageQueue [topic=XXXX, brokerName=qdinternetorder-02, queueId=5] 1013923
說明：
這種現象說明消息已經消費成功、并且在MQ服務端已持久化消費進度；MessageQueue裡包括了消息主題、對應的brokerName,消費隊列的id
解決方案：
暫無
HeartbeatData [clientID=XXX, producerDataSet=[
ProducerData [groupName=XXXX], ProducerData [groupName=XXX]], consumerDataSet=[]]
send heart beat to broker[XX] success
該現象是向服務端發送心跳包成功，HeartbeatData是心跳相關的資訊，包括用戶端id、發送組資訊、消費組資訊
[PULL_TPS] [CID_XXXX@CID_XXXX] Stats In One Minute, SUM: 0 TPS: 0.00 AVGPT: 0.00
[PULL_RT] [%RETRY%CID_XXXX@CID_XXXX] Stats In One Minute, SUM: 0 TPS: 0.00 AVGPT: 0.00
該類資訊列印的是從consumeQueue中拉取消息時的TPS（每秒request的數量）
[TIMEOUT_CLEAN_QUEUE]broker busy, start flow control for a while, period in queue: 905ms, size of queue: 1164
服務端壓力過大、處理不了過多的請求；由于mq服務端在存儲資料時是先寫入pageCache,然後去刷盤、是以每隔10s會去清理過期的請求（此過程會判斷緩存頁是否繁忙）
（1）擴容，增加broker，分擔壓力
（2）osPageCacheBusyTimeOutMills屬性值調大
execute the pull request exception
com.aliyun.openservices.shade.com.alibaba.rocketmq.client.exception.MQBrokerException: CODE: 25 DESC: the consumer's subscription not lates
1）、updateConsumeOffsetToBroker日志是正常的，是一個定時任務，定期同步offset到Broker；
2）、theconsumer's subscription not latest這個日志在重新開機後是目前的一個正常處理邏輯，為了達到"Consumer叢集的負載均衡"的一種機制：當一個新的consumer程序加入，用戶端需要重新配置設定queue以實作負載均衡，此時會短暫的阻止pull請求，直到該consumer被重新配置設定了queue；
[WRONG]mq is consuming, so can not unlock it, MessageQueue [topic=XX, brokerName=szorder2-02, queueId=1]. maybe hanged for a while, 2
進行負載均衡時，對消息處理隊列嘗試加鎖，如果1s内還未加鎖成功，說明目前消息處理隊列已經有消費者在通路，不能進行解鎖
7、
doRebalance, XXX-CID, add a new mq failed, MessageQueue [topic=XXXX, brokerName=szorder2-02, queueId=5], because lock failed
使用者使用的是順序Topic，為了保證單個分區中消息的順序消費，這個會有個lock的機制。用戶端有這個日志說明其中某個分區已經有用戶端在消費了。
8、
get Topic [XXXXXX] RouteInfoFromNameServer is not exist value
com.aliyun.openservices.shade.com.alibaba.rocketmq.client.exception.MQClientException: CODE: 17 DESC: No topic route info in name server for the topic: TOPIC_XXXXX
See
http://rocketmq.apache.org/docs/faq/for further details.
nameServer 清單非空，可連接配接到 nameServer ，但 topicList 為空，或 topicList 狀态 非 OK ，比如 curl 接入點 onsaddr 異常。
（1）AK/SK配置錯誤
（2）使用者沒有控制台于目前執行個體下建立了GID
（3）執行個體化的代碼中，NameServerAddr沒有配置正确
（4）确認topic權限可用，topic 要求 permission 是 6（rw-）至少為 2（-w-），用mqadmin topicRoute 可排查路由資訊
9、
com.aliyun.openservices.ons.api.impl.authority.exception.AuthenticationException: signature validate by dauth failed
AK/SK配置錯誤
AK/SK要配置建立該GID使用的AK/SK
10、
NettyClientPublicExecutor_3 - execute the pull request exception
com.aliyun.openservices.shade.com.alibaba.rocketmq.client.exception.MQBrokerException: CODE: 26 DESC: subscription group [CID_XXX] does not exist,
http://rocketmq.apache.org/docs/faq/forfurther details.
訂閱關系沒有推送到MQ伺服器上
subscription.json檔案裡直接添加GID對應的資訊即可
11、
execute the pull request exception
com.aliyun.openservices.shade.com.alibaba.rocketmq.client.exception.MQBrokerException: CODE: 24 DESC: the consumer's subscription not exist
缺少訂閱關系
12、
sendKernelImpl exception, resend at once, InvokeID: -4054089080884425405, RT: 7183ms, Broker: MessageQueue [topic=xxxx, brokerName=xxx, queueId=2]
com.aliyun.openservices.shade.com.alibaba.rocketmq.remoting.exception.RemotingTimeoutException: wait response on the channel
https://help.aliyun.com/document_detail/63390.html?spm=a2c4g.11186623.6.622.263812bdTfeFRo