消息消費常見問題
客戶端首次接入連接不上服務端，收不到消息如何排查？
請檢查以下配置是否填寫正確：
檢查接入點是否填寫正確。接入點請從控制臺實例詳情頁面獲取。
使用telnet 接入點域名端口命令初步檢查網(wǎng)絡連通性。
若您的應用部署在本地、或需要跨地域訪問且無法使用CEN組網(wǎng)，您需要使用公網(wǎng)接入點訪問云消息隊列 RocketMQ 版實例。使用公網(wǎng)接入點會產(chǎn)生下行流量費用，具體信息，請參見4.x系列公網(wǎng)訪問費用或5.x系列公網(wǎng)訪問費用。
若您的應用部署在阿里云ECS上，您可以使用VPC接入點通過VPC專有網(wǎng)絡訪問云消息隊列 RocketMQ 版實例。該場景下，需要保證阿里云ECS的地域和要訪問的云消息隊列 RocketMQ 版實例處于同一地域。
5.0系列實例若開啟公網(wǎng)訪問，請確認是否有配置白名單。公網(wǎng)訪問默認全部地址放行，若配置了白名單則僅白名單中的IP地址允許訪問云消息隊列 RocketMQ 版。
檢查Topic名稱是否填寫正確，不要有多余空格或特殊字符，并確保Topic已在控制臺提前創(chuàng)建。
檢查用戶名密碼是否設置正確。
5.0系列實例：需要填寫實例的用戶名和密碼，在控制臺實例詳情頁獲取。
4.0系列實例：需要填寫阿里云賬號或RAM用戶的AccessKey（AccessKey ID和AccessKey Secret）并正確授權。獲取方式，請參見創(chuàng)建AccessKey。
訂閱關系不一致如何處理？
登錄控制臺，進入Group 管理頁面，查看指定Group的訂閱關系及消費者信息，將不符合預期的消費者的訂閱代碼中的訂閱關系修改一致。
如何處理消息堆積？
消息出現(xiàn)堆積，可能原因如下：
消費者消息處理邏輯異常，導致消息無法正常消費。
消息生產(chǎn)應用出現(xiàn)突發(fā)流量，消息生產(chǎn)速度遠大于消費速度，消息來不及消費出現(xiàn)堆積。
消費者依賴的下游服務耗時變長，消費線程阻塞等。
消費線程不夠，消費并發(fā)度較小，消費速度跟不上生產(chǎn)速度。
您需要查看客戶端日志或客戶端堆棧信息，確定異常原因，具體操作，請參見如何處理消息堆積。
消費者消費不到消息如何處理？
登錄云消息隊列 RocketMQ 版控制臺，進入Group 管理頁面，查看消費者是否在線，客戶端連接是否正常，若客戶端未連接，查看客戶端日志根據(jù)報錯修改異常。
查看訂閱關系是否一致，若不一致根據(jù)訂閱關系的分布情況定位消費者客戶端，修改客戶端的訂閱消息代碼。
若某個消費組下的機器宕機，機器重啟期間，消息會不會丟失？
云消息隊列 RocketMQ 版的訂閱是持久化訂閱，ConsumerGroup下線或消費異常時，消息不會丟失。當消費者客戶端重新上線后，直接從下線前的消費位點繼續(xù)消費消息。
訂閱消息時消息Tag是否可以為空？
訂閱消息時Tag設置為空會導致消費者消費不到任何消息。若您希望訂閱Topic中的所有消息，則需要將Tag設置為*。示例代碼如下：
String topic = "Your Topic";
//使用Tag標簽過濾消息，訂閱所有消息。
FilterExpression filterExpression = new FilterExpression("*", FilterExpressionType.TAG);
pushConsumer.subscribe(topic, filterExpression);更多信息，請參見Tag標簽過濾。
創(chuàng)建新的消費分組訂閱舊的Topic，如何設置消費起始位置？
消費者分組創(chuàng)建時不支持設置消費起始位置，不管是訂閱新的Topic還是舊的Topic，消費者第一次啟動時都會默認從Topic中的最早一條消息開始消費。
消費者在線無消費消息，但Group有堆積
請檢查消費者使用Group對Topic的訂閱方式。如果消費者采用消息過濾方式訂閱Topic，未命中過濾條件的消息會被計算為堆積，符合設計預期。詳情參見消息過濾。
采用SQL/TAG消費過濾的方式，未消費到消息但Group有消息堆積，堆積量的計算如下所示。
SQL消費方式：堆積量 = 已就緒的消息量 + 處理中的消息量 - 未被SQL命中的消息數(shù)量。
TAG消費方式：堆積量 =（已就緒的消息量 + 處理中的消息量）* TAG標簽消息百分比。
TAG標簽消息百分比 = 采樣內(nèi)TAG標簽消息量 / 采樣消息總量
儀表盤消息堆積量指標顯示消息有大量堆積，但排查消費側，消息已被消費
如果采用Remoting協(xié)議SDK，并在消費端將消費方式設置為廣播消費，則會產(chǎn)生這種現(xiàn)象。服務端依據(jù)消息位點信息判斷堆積情況，而廣播消費模式下消費位點是在客戶端維護的，因此會看到消息堆積的情況。
消費端在采用TAG/SQL過濾方式進行消費時，未滿足過濾條件的消息將被視為消息堆積。