linux運(yùn)維包30rocket mq使用排查指南

MQ原理及快速 4 MQ快 告警相關(guān)問 MQ原理及快速什么是消息隊(duì) 消息隊(duì)列MQ版是阿里云基于ApacheMQ構(gòu)建的低延遲、高并發(fā)、高可用、高可靠的分布式消息中間件。消息隊(duì)列MQ版既可為分布式消息隊(duì)列MQ版提供TCP和HTTP協(xié)議的多語言接入方式，方便不同編程語言開發(fā)的應(yīng)用快速接入消息隊(duì)列MQ版消息云服務(wù)。您可以將應(yīng)用部署在阿里云ECS、企業(yè)自建云，或者嵌入到移動(dòng)端、物聯(lián)網(wǎng)設(shè)備中與消息隊(duì)列MQ版服務(wù)進(jìn)行消息收發(fā)。NameServer：是一個(gè)幾乎無狀態(tài)節(jié)點(diǎn)，可集群部署，在消息隊(duì)列-MQ版中提供命名服務(wù)，更新和發(fā)現(xiàn)Broker服務(wù)。Broker：消息中轉(zhuǎn)角色，負(fù)責(zé)消息，轉(zhuǎn)發(fā)消息。分為MasterBroker和SlaveBroker，一個(gè)MasterBroker可以對(duì)應(yīng)多個(gè)SlaveBroker，但是一個(gè)SlaveBroker只能對(duì)應(yīng)一個(gè)MasterBroker。Broker啟動(dòng)后需要完成一次將自己至NameServer的操作；隨后每隔30s定期向NameServer上報(bào)Topic路由信息。生產(chǎn)者：與NameServer集群中的其中一個(gè)節(jié)點(diǎn)（隨機(jī)）建立長（Keep-alive），定期從NameServerTopic路由信息，并向提供Topic服務(wù)的MasterBroker建立長，且定時(shí)向MasterBroker發(fā)送心跳。NameServer（隨機(jī)）建立長連接，定期從訂閱消息，訂閱規(guī)則由Broker配置決定。流量削峰也是消息隊(duì)列MQ版的常用場(chǎng)景，一般在秒殺或團(tuán)隊(duì)搶購活動(dòng)中處理如此大量的流量后，下游系統(tǒng)無法承載海量的調(diào)用量，甚至?xí)?dǎo)致系統(tǒng)等問題而發(fā)生漏通知的情況。為解決這些問題，可在應(yīng)用和下游通知系統(tǒng)之間加入消息隊(duì)列MQ版。 假設(shè)每個(gè)任務(wù)耗時(shí)分別為50ms，則用戶需要在頁面等待總共需要150 假設(shè)每個(gè)任務(wù)耗時(shí)分別為50ms，其中，郵件和通知并行完成，則用戶需要在頁面等待總共需要100ms才能登錄。以下就場(chǎng)景中使用了消息隊(duì)列MQ版的效果進(jìn)行說明對(duì)于系統(tǒng)而言，發(fā)送成功的和郵件通知并不一定要綁定在一起同步信息寫入系統(tǒng)成功后，再發(fā)送消息至消息隊(duì)列MQ版。消息下游的郵件和通知系統(tǒng)訂閱消息隊(duì)列MQ版的此類請(qǐng)求消息用戶只需在頁面等待數(shù)據(jù)寫入系統(tǒng)和消息隊(duì)列MQ版的時(shí)間，即等待55ms即可登錄。消息隊(duì)列MQ版順序消息分為兩種情況全局順序：對(duì)于指定的一個(gè)Topc，所有消息將按照嚴(yán)格的先入先出FIF的分區(qū)順序：對(duì)于指定的一個(gè)Toic，所有消息根據(jù)hadingKey進(jìn)行區(qū)塊分區(qū)，同一個(gè)分區(qū)內(nèi)的消息將按照嚴(yán)格的F的順序，進(jìn)行順發(fā)布和順序消費(fèi)，可以在場(chǎng)景中，可使用用戶ID作為ShardingKey來進(jìn)行分區(qū)，同一個(gè)分區(qū)下的新建、更新或刪除信息的消息必須按照FIFO的順序發(fā)布和消費(fèi)。將信息寫入系統(tǒng)之后，發(fā)送一條成功的消息到消息隊(duì)列MQ版，郵件通知系統(tǒng)訂閱消息隊(duì)列MQ版的消息，做相應(yīng)的業(yè)務(wù)處理，發(fā)送系統(tǒng)向消息隊(duì)列MQ版發(fā)送消息成功與否的消息消發(fā)失，致件系未到息列MQ的成功與否的消息，而無法發(fā)送郵件，最終郵件通知系統(tǒng)和郵件通知系統(tǒng)收到消息隊(duì)列MQ版的成功消息系統(tǒng)向消息隊(duì)列MQ版發(fā)送半事務(wù)消息2.1成功，進(jìn)入3.12.2失敗，進(jìn)行3.2系統(tǒng)向消息隊(duì)列MQ版發(fā)送半消息狀態(tài)。郵件通知系統(tǒng)接收消息隊(duì)列MQ版的成功消息雙十一大促時(shí)，各個(gè)分會(huì)場(chǎng)會(huì)有玲瑯滿目的商品，每件商品的價(jià)格都會(huì)實(shí)時(shí)變化。使用緩存技術(shù)也對(duì)商品價(jià)格的需求，存服務(wù)器網(wǎng)卡滿載。較普通消息是指消息隊(duì)列MQ版中無特性的消息，即發(fā)送到服務(wù)端會(huì)立馬被Producer將消息發(fā)送到消息隊(duì)列MQ版服務(wù)端，但并不期望立馬投遞這條消息，而是推在當(dāng)前時(shí)間點(diǎn)之后的某一個(gè)時(shí)間投遞到Consumer進(jìn)行消費(fèi)，該P(yáng)roducer將消息發(fā)送到消息隊(duì)列MQ版服務(wù)端，但并不期望立馬投遞這條消息，而是延遲一定時(shí)間后才投遞到Consumer進(jìn)行消費(fèi)，該消息即延時(shí)消息。息在發(fā)送到消息隊(duì)列MQ版服務(wù)端后并不會(huì)立馬投遞，而是根據(jù)消息中的屬對(duì)于指定的一個(gè)Tpc，所有消息按照嚴(yán)格的先入先出FIF的順序進(jìn)行發(fā)布對(duì)于指定的一個(gè)Topic，所有消息根據(jù)ShardingKey進(jìn)行區(qū)塊分區(qū)。同一個(gè)分區(qū)內(nèi)的消息按照嚴(yán)格的FIFO順序進(jìn)行發(fā)布和消費(fèi)。ShadingKey是順序消息中用來區(qū)分不同分區(qū)的關(guān)鍵字段，和普通消息的MessageKey是完全不同的概念。消息隊(duì)列MQ版提供類似X/OpenXA的分布事務(wù)功能，通過消息隊(duì)SDK支持語言及協(xié)議其中推薦使用阿里推出的tcpsdk：java，C/C++，.NET除了阿里推出的sdk，我們還支持開源的多語言sdk接入阿里云MQ：如果您想使用多語言的sdk，推薦使用http協(xié)議接入： MQ如果您使用的是阿里云主賬號(hào)，則可以通過本文來體驗(yàn)從開通服務(wù)、創(chuàng)建資源、用SDK列MQ無論您使用的是消息隊(duì)列MQ版支持的何種協(xié)議、何種語言，前三個(gè)步驟用SDK時(shí)，不同協(xié)議和語言的示例代碼有所不同，本文以TCP協(xié)議下的JavaSDK在消息隊(duì)列MQ版產(chǎn)品頁，單擊立即開通在使用消息隊(duì)列MQ版時(shí)，請(qǐng)注意以下網(wǎng)絡(luò)限制Regio華東1（杭州）下的實(shí)例A中創(chuàng)建的GroupID對(duì)應(yīng)的生產(chǎn)端和消費(fèi)端。如果只是測(cè)試，或者需要在本地（非阿里云ECS服務(wù)器）使用消息隊(duì)列MQ版的服務(wù)，請(qǐng)將Topic和GroupID都創(chuàng)建在公網(wǎng)地域下的實(shí)例中。生產(chǎn)端和消費(fèi)端可以部署在本地或者部署在任意地域的ECS上，前提是本地服務(wù)器或者相應(yīng)的ECS需要能夠公網(wǎng)。實(shí)例是用于消息隊(duì)列MQ版服務(wù)的虛擬機(jī)資源，會(huì)消息登錄消息隊(duì)列MQ版控制臺(tái)。在頁面頂部導(dǎo)航欄，選擇地域，如公網(wǎng)Topic是消息隊(duì)列MQ版里對(duì)消息的一級(jí)歸類，例如可以創(chuàng)建Topic_Trade這一Topic來識(shí)別類消息，消息生產(chǎn)者將消息發(fā)送到Topic_Trade，而消息消費(fèi)者則通過訂閱該Topic來獲取和消費(fèi)消息。Topic不能跨實(shí)例使用，例如在實(shí)例A中創(chuàng)建的opicA不能在實(shí)例B中您可創(chuàng)建不同的opic來發(fā)送不同類型的消息，例如用TopicA發(fā)送普通消息，TopicBTopicC在創(chuàng)建Topic框中的Topic一欄，輸入Topic名稱，選擇該Topic對(duì)應(yīng)的消息類型，輸入該Topic的備注內(nèi)容，然后單擊確定。Group創(chuàng)建完實(shí)例和opic后，您需要為消息的消費(fèi)者（或生產(chǎn)者）創(chuàng)建客戶端ID，即GroupID作為標(biāo)識(shí)。GroupIDGroupID和Topic的關(guān)系是N：N，即一個(gè)消費(fèi)者可以訂閱多個(gè)Topic，同一個(gè)opic也可以被多個(gè)消費(fèi)者訂閱；一個(gè)生產(chǎn)者可以向多個(gè)opic發(fā)送消息，同一個(gè)Topic也可以接收來自多個(gè)生產(chǎn)者的消息。在控制臺(tái)左側(cè)導(dǎo)航欄，單擊Group在Group管理頁面上方選擇剛創(chuàng)建的實(shí)例，然后選擇TCP協(xié)議>創(chuàng)建GroupIDTCP說明：TCP和HTTPGroupID在創(chuàng)建GroupID框中，輸入GroupID和描述，然后單擊確認(rèn)創(chuàng)建阿里云阿里云AccessKey在調(diào)用SDK發(fā)送和訂閱消息的時(shí)候，除了需要指定創(chuàng)建的Topic和Group以外，還需輸入您在RAM控制臺(tái)創(chuàng)建的驗(yàn)證信息，即AccessKey。在默認(rèn)顯示的實(shí)例信息頁簽的獲取接入點(diǎn)信息區(qū)域，您可以分別看到新創(chuàng)建實(shí)例的TCP和HTP協(xié)議接入點(diǎn)。接入點(diǎn)性質(zhì)因協(xié)議而異，具體說明如下：TCP協(xié)議：您在控制臺(tái)看到的TCP協(xié)議接入點(diǎn)是地域下某個(gè)具體實(shí)例的接入HTTP協(xié)議：您在控制臺(tái)看到的HTTP協(xié)議接入點(diǎn)是某個(gè)地域的接入點(diǎn)，跟具體實(shí)例無關(guān)。您在收發(fā)消息時(shí)還需另外設(shè)置實(shí)例ID。在TCP協(xié)議的接入點(diǎn)區(qū)域，單擊對(duì)于TCP協(xié)議的接入點(diǎn)，您還可以單擊示例代碼，查看在各種開發(fā)語言的程序完成以上準(zhǔn)備工作后，您就可以運(yùn)行示例代碼，用消息隊(duì)列MQ版進(jìn)行消在發(fā)送消息框中的MessageBody一欄，輸入消息的具體內(nèi)容，單擊確控制臺(tái)會(huì)返回消息發(fā)送成功通知以及相應(yīng)的MessageID調(diào)用SDK發(fā)送消息：用于生產(chǎn)環(huán)境下使用消息隊(duì)列MQ版。下文以調(diào)用TCPJavaSDKTCPJavaSDKMaven //設(shè)置為JavaSDK 版本依賴JARimportcom.aliyun.openservices.ons.api.Message;importcom.aliyun.openservices.ons.api.Producer;importcom.aliyun.openservices.ons.api.Message;importcom.aliyun.openservices.ons.api.Producer;importjava.util.Properties;publicclassProducerTestpublicstaticvoidmain(String[]{Propertiesproperties=new//您在控制臺(tái)創(chuàng)建的GroupID //鑒權(quán)用AccessKeySecret，在阿里云服務(wù)器管理控制臺(tái)創(chuàng)建 /設(shè)置TCP接入 ，進(jìn)入控臺(tái)的實(shí)例詳情頁面，在頁面上方選擇例后，在實(shí)例信息的“獲取接入點(diǎn)信息”區(qū)域查看ProducerProducerproducer=//在發(fā)送消息前，必須調(diào)用start方法來啟動(dòng)Producer，只需調(diào)用一次即可//Messagemsg=newMessage(//在控制臺(tái)創(chuàng)建的Topic，即該消息所屬的Topic//Message//可理解為Gmail中 ，對(duì)消息進(jìn)行再歸類，方便Consumer指定過濾條件在消息隊(duì)MQ//Message//任何二進(jìn)制形式的數(shù)據(jù)，消息隊(duì) MQ版不做任何干預(yù)//需要Producer與Consumer 設(shè)置代表消息的業(yè)務(wù)關(guān)鍵屬性，請(qǐng)盡可能全局唯一，以方便您在無法正常收到消息情況下，可通過控制臺(tái)查詢消息并補(bǔ)發(fā)//注意//MessageID，以便用于消息發(fā)送狀態(tài)查詢System.out.println("SendMessagesuccess.MessageIDis:"+sendResult.}//在應(yīng)用退出前，可以銷毀Producer//注意}}MessageID在搜索框中輸入發(fā)送消息后返回的MessageID，單擊搜索查詢消息發(fā)送狀態(tài)。時(shí)間表示消息隊(duì)列MQ版服務(wù) 步驟五：調(diào)用SDK訂閱消息importimportcom.aliyun.openservices.ons.api.Consumer;importcom.aliyun.openservices.ons.api.Message;importcom.aliyun.openservices.ons.api.MessageListener;importcom.aliyun.openservices.ons.api.ONSFactory;publicstaticvoidmain(String[]{Propertiesproperties=new//您在控制臺(tái)創(chuàng)建的GroupID //鑒權(quán)用AccessKeySecret，在阿里云服務(wù)器管理控制臺(tái)創(chuàng)建 /設(shè)置TCP接入 ，入控制臺(tái)的實(shí)例詳情頁面，在頁面上選擇實(shí)例后，在實(shí)例信息的“獲接入點(diǎn)信息”區(qū)域查看Consumerconsumer=ONSFactory.createConsumer(properties);consumer.subscribe("TopicTestMQ","*",newMessageListener(){publicActionconsume(Messagemessage,ConsumeContext }System.out.println("ConsumerSystem.out.println("Consumer}}完成上述步驟后，您可以在控制臺(tái)查看消費(fèi)者是否啟動(dòng)成功，即消息訂閱是否成功。在控制臺(tái)左側(cè)導(dǎo)航欄，單擊GroupGroupIDGroupID如果是否顯示為是，且訂閱關(guān)系一致，則說明訂閱成功。否則說明訂閱通過消息軌跡查詢到，MQTPSip的連接情況、確認(rèn)期間應(yīng)用是否有FullGC(FullGC可結(jié)合ons.log來綜合分析?？聪潞蠖说膖opic集群是否有問題。延時(shí)消息我們會(huì)先存DB，在指定的時(shí)間掃描DB，再將消息到broker上，也是因?yàn)檫@個(gè)DB和掃碼的DB的損耗，所以我們的定時(shí)消息性能是沒有普通消息高的。普通消息是直接發(fā)送到broker上的。延時(shí)消息就是多了兩層的消為什么用普通消息的topic發(fā)送延遲消息也可以成功比如創(chuàng)建的普通消息類型toic但是發(fā)送延時(shí)消息也是可以使用的。總結(jié)來:topic消息類型有作用嗎。tpi，并且發(fā)送相應(yīng)類型的消息，性啟動(dòng)發(fā)送端錯(cuò)Norouteinfoofthistopic。檢查您代碼的接入點(diǎn)配置，是否是MQ 確認(rèn)NameServer可用，curl接入點(diǎn)，將獲得的地址和端也 topic權(quán)限可用，檢查您代碼中配置的AK、SKrgion（如果是走的公網(wǎng)，阿里云生產(chǎn)環(huán)境中消息隊(duì)列ForMQ除了公網(wǎng)region之外，其他服務(wù)端限流system|brokerons.log日志當(dāng)中出現(xiàn)systembusy,startflowcontrolforawhile重試策略,會(huì)重試到其它的broker，不影響消息的發(fā)送。uid/1.8.4skd會(huì)自定進(jìn)行brokerbusygfailed或者RemotingTimeoutException等異常信息。MQmq群部署的,一臺(tái)網(wǎng)絡(luò)的閃斷是不會(huì)影響消息的。在自己的應(yīng)用服務(wù)器上執(zhí)行eokrport，確認(rèn)服務(wù)端的端口是否題時(shí)間點(diǎn)流量是否有下降的情況。如果或者net不通，需要檢查服務(wù)器的，網(wǎng)絡(luò)設(shè)置等。統(tǒng)有沒有FullGC(FullGC會(huì)造成一定的網(wǎng)絡(luò)延遲)。確認(rèn)下使用的sdk，如果是較低的javadk版本，建議升級(jí)sdk版本到comyun.oescesosapexcepon.ONSExceponCannotfindnameserverwithonsAddrhttp://**** Seehttp /cn#/pub/ons/faq/exceptions&namesrv_not_existforfurtherdetails. com.yun.opensicesonsapmp.qONSetchNaeServerAddr(ONSatcom.aliyun.openservices.ons.api.impl.mq.ONS.<init>(ONS. spimdu 開源python發(fā)送端發(fā)送報(bào)錯(cuò)使用開源python的tcp提供的demo，發(fā)送報(bào)錯(cuò)供的tcp的接入點(diǎn)。Php的httpd//topic/sdk語言版本等信息收集反饋給到技NumberFormatException:Forinputstring:"http://XXX"NumberFormatException:Forinputstring:sdkMQpomons-sdk采用mvndependency:tree如果是打出去的是jar包，將生成的jar解壓，然后在lib 或者是com.ayn.openservices.onsamuthoecen.AuthenExcenvalidresourceownerfaled.AK、SKTopicGID的賬號(hào)并不匹sdk報(bào)錯(cuò)信息?？梢钥聪聅dk版本是否是1.7.9版本的。如果是，建議升級(jí)sdk。1.7.9版本的sdk在鑒權(quán)的時(shí)候，的確會(huì)容易出現(xiàn)鑒權(quán)失敗的問題，此版本在健全上有一些bug。id//topic/sdk版本等信息給 CODE:1DESC:[REJECTREQUEST]BrokernslavemodeCODE：13themessageisillegal,maybemsgbodyorpropertieslengthnotmatched.msgCODE：13themessagebodysizeovermaxvalue 4MB這個(gè)上限值不能修改，這個(gè)會(huì)影響全局性能。如果消息體的確很大，建應(yīng)用部署在edasmqedas通過發(fā)送報(bào)錯(cuò)日志看到是ons--1.7.1-EagleEye.jar報(bào)錯(cuò)，ons-的版本比較低，需要升級(jí)ons-sdk1.8.0-EagleEye插件。發(fā)送錯(cuò)fetchnameserveraddressfetchnameserveraddressexception根據(jù)代碼配置中的ONSAddrNAMESRV_ADDRONSAddr錯(cuò)NAMESRV_ADDRONSAddr，進(jìn)行了如下圖配置。nslookup接入點(diǎn)的看下。檢查dns是否正確。正確情況下，會(huì)獲取到nslookuponsaddr-發(fā)送消息報(bào)錯(cuò)notsetanyresponsemessagepropertiesPagedTopic，openApiOnsMessagePageQueryByTopic。登錄mq控制臺(tái)，打開瀏覽者開發(fā)工具（winos:F12macos:command+查看properties里是否存在長度比較長的屬性值。 里可查 List>>MessagePropertytionException:getuserinfobyaccesskeyfromALIYUNfailed.AKakak啟動(dòng)發(fā)送者 啟動(dòng)消息隊(duì)列MQ版的客戶端時(shí)提示異常導(dǎo)致此問題的主要原因是客戶端無法獲取系統(tǒng)的主機(jī)名Hostna的IP執(zhí)行hostname如果該命令報(bào)錯(cuò)，請(qǐng)檢查是否為該命令定義了別名（alias，比如bash_profile.bashrcaliashostname='/usr/bin/****'的別名。確保hostname命令能夠正常返回主機(jī)名。如果無法通，請(qǐng)參考[$Hostname]，將記錄的主機(jī)名綁定到/etc/hosts文件中。如果可以通，請(qǐng)繼續(xù)下一步。/etc/sysconfig/networkHostname/etc/hosts值，使其與/etc/hosts文件中的主機(jī)名一致。/etc/sysconfig/networkHostnamehostnamectlset-hostname[$Hostname]重新啟動(dòng)消息隊(duì)列MQ版的客戶端，確認(rèn)不再提示有關(guān)未知主機(jī)名發(fā)送消息錯(cuò)消息不合法Tcp協(xié)議開源sdk連接mq失敗開源sdk接入阿，阿都是與各個(gè)開源語言的sdk做過適配的。因此一定需要使用阿文檔上推薦的各個(gè)語言的sdk版本，如果使用的開源版本非 mq的Java進(jìn)程消息堆積嚴(yán)重消費(fèi)者狀態(tài)頁面，GroupIDMQ所對(duì)應(yīng)的宿主機(jī)IP，并登錄該宿主機(jī)或容器。psps-ef|grepjpsjstack-lpid>catcat/tmp/pid.jstack|grepConsumeMessageThread-A10BLOCKED此狀態(tài)說明消費(fèi)者線程被阻塞了，導(dǎo)致消息的消費(fèi)被停滯了，從而WAITING如果不是上圖所顯示的堆棧信息，可以重復(fù)上面的3、4兩步，檢查這個(gè)這間較長，從而導(dǎo)致消息消費(fèi)的耗時(shí)增長，TPS下降，消息消費(fèi)的速度跟不上這個(gè)上限不是擠壓的或者mq端大量堆積導(dǎo)致程序高負(fù)載運(yùn)行的上限，是正常消這個(gè)是產(chǎn)品側(cè)的一個(gè)策略，無法做到堆積后再均衡對(duì)堆積量做進(jìn)一步對(duì)均衡分廣播模式下控制臺(tái)看到的這個(gè)堆積數(shù)據(jù)是無效的，廣播模式下服務(wù)端不消費(fèi)進(jìn)度，消費(fèi)進(jìn)度在客戶端，所以是否有堆積這個(gè)需要您客戶端來，廣播模式下我們服務(wù)端不消費(fèi)進(jìn)度，您的消費(fèi)端的消費(fèi)位點(diǎn)，我們這邊不保存，這個(gè)只能B這個(gè)堆積量也是包含曾經(jīng)訂閱A的堆積量。tpic是不是有目toic的位點(diǎn)清除下，那么這個(gè)消費(fèi)者的topicmq是否支持積壓消息后批量消費(fèi)消息有一定的量，而不是1個(gè)，主要目的是想提升批量。MQ現(xiàn)在的消費(fèi)模式本身就是push的。tsumeMessageBataxSize取值范圍為1-32。mq的消費(fèi)邏輯是這樣的，啟動(dòng)消費(fèi)者之后，消費(fèi)者會(huì)一直perm64mq95%50。pod的代碼部署的是一樣的就是一套代碼，都去作為消費(fèi)者。sardngKey不太合適。導(dǎo)致消息發(fā)送打散的不夠均勻.，基本上都集中少量邏輯分區(qū)里面了。量.分布就會(huì)均勻了.不是隨機(jī)。id/或者訂單號(hào),就是更好一些的選擇。面又刪除了，然后短時(shí)間內(nèi)又創(chuàng)建了這個(gè)opc，就會(huì)導(dǎo)致這個(gè)問題?？梢詃//topic等信息給到技術(shù)人員進(jìn)行進(jìn)一步消費(fèi)者rebalanceservice線程這個(gè)是消費(fèi)端負(fù)載均衡的線程。是一個(gè)正常狀態(tài)的線程。lc是有時(shí)間間http舉例topic5，14但是這個(gè)四個(gè)沒訂閱的tg，topic當(dāng)中有堆積了，這個(gè)堆積量也會(huì)顯示在控制臺(tái)10MQ消費(fèi)端到mq當(dāng)中拉到消息進(jìn)行消費(fèi)之后，會(huì)反饋給mq已經(jīng)成功拿到消息并toic當(dāng)中就會(huì)再次可見，那么消費(fèi)者就可以再次來拉取這個(gè)消息（重第一次發(fā)消息算是第0次，如果在10秒內(nèi)沒有給mq反饋，那么這個(gè)消息就會(huì)再次可見，消費(fèi)端就會(huì)再去拉取這個(gè)消息，就是第一次重試了，如果在10秒之后，消費(fèi)者給了第一次發(fā)消息（0）的響應(yīng)，那么這個(gè)消費(fèi)也是失敗的。比如消費(fèi)者10s30所以建議業(yè)務(wù)邏輯放在返回給mq消息的代碼之前，最好是保證10秒之內(nèi)要給到mq響應(yīng)?？梢詫I(yè)務(wù)邏輯放在其他地方做并發(fā)處理。https /_detail/44397.html?spm=5176. 如果是大量消息重復(fù)消費(fèi)，需要核實(shí)您的代碼是否和mq提供的一致，在重復(fù)消費(fèi)消息的時(shí)候，消費(fèi)端的網(wǎng)絡(luò)情況，是否有fullgc等。id//topic/msgid等，給到技術(shù)支持人員進(jìn)行確認(rèn)。 mitMessage才 掉這條消息后，BAction.ReconsumeLater后消息是否會(huì)重發(fā)，重發(fā)是發(fā)給B還是A,B,C都會(huì)收到。MaxReconsumeTimes00后將不在重試。間段broker壓力比較大的時(shí)候，消費(fèi)失敗重試會(huì)有一定的延遲?？梢远鄼zid//topic/msgid等信息給技是偶爾消費(fèi)一兩條/為什么一條消息被重復(fù)消費(fèi)了？GropIDCosumer輯必須完全一致。一旦訂閱關(guān)系不一致，消息消費(fèi)的邏輯就會(huì)，甚至導(dǎo)致消息丟失。由于消息隊(duì)列MQ版的訂閱關(guān)系主要由Topic+Tag共同組成，因此，保持訂閱關(guān)系一致意味著同一個(gè)消費(fèi)者GroupID下所有的消費(fèi)者實(shí)例需在以下兩方TopicTaghttp的消費(fèi)者看不到訂閱關(guān)系2019-11-1820:29:04,004WARNmq-executethepullrequestexceptioncman. .alibaba.mq.tion:CODE:26DESC:subscrptiongroup[MQ_INST_****_BaSllRRw%GID_****]doesnotexist,Seeforfurtherdetails.GID已超過10min25s。CPU或內(nèi)存消耗過高導(dǎo)致，一般是業(yè)務(wù)代碼處理復(fù)雜和線程數(shù)一個(gè)topic如果從來沒有任何一個(gè)gid連接消費(fèi)過，假設(shè)這個(gè)topic當(dāng)中已經(jīng)有一千萬條消息發(fā)進(jìn)來了，第一個(gè)啟動(dòng)的gid topicgidgid連接，是會(huì)去消費(fèi)topic當(dāng)中還存在的，tag匹配的消息的。java代碼為例，可以使用newString(message.getBody())來獲取消息體消費(fèi)消息時(shí)ack報(bào)錯(cuò)ackErrorMessageThereceipthandleyouprovidedhasexpired.codeMessageNotExist。會(huì)分配到一個(gè)broker一個(gè)queue。ahtrycath異常直接返回成功狀態(tài)，該條消息則不會(huì)再重試消費(fèi)者出現(xiàn)rebalanceService線程rebalanceService確認(rèn)發(fā)送延時(shí)消息的api是否和提供的demo是一致的如果核實(shí)這兩者都沒有問題，需要將實(shí)例d/地域/topic/gid/發(fā)送代碼信息如果檢查發(fā)現(xiàn)使用的api都正確，這時(shí)可以通過消息軌跡和消息的時(shí)間如果以上都排查了，沒有問題，需要將實(shí)例d/地域/topc/gid/發(fā)送消費(fèi)代業(yè)務(wù)上核實(shí)是否真的沒有收到該消息，mq是保證以消息準(zhǔn)確到達(dá)服務(wù)端被查看下發(fā)送的時(shí)間段，的發(fā)送量和消費(fèi)量對(duì)比，看下是否處于一個(gè)業(yè)2019-07-0516:46:39,039WARNmq-thecachedmessagecountexceedsthethreshold1000,sodoocontrol,nOfaOset=573count=1008,sze=MiBpuRequest=PuRequs【consumerGroup=GID_MR_SG_ACTIVITY_TEST,messageQueue=MessageQueue【MR_SG_USER_TASKNOA_TESbroker-Name=hz-share2-03,queueId=7nextOffset=5739flowControlTimes=建議配置上堆積。配置后超過多少堆積告警，或者考慮增加消費(fèi)實(shí)例，讓消費(fèi)能力稍微大于生成能力。確認(rèn)是否為集群消費(fèi)（因廣播模式下，消費(fèi)位點(diǎn)都由客戶端本地，因此確認(rèn)sdksdk（建議升級(jí)sdk,至少是c中的，如果選擇的是清除所有堆積消息，從位點(diǎn)開始消費(fèi)方式重置消費(fèi)位同一條消息，為什么發(fā)送方和訂閱方的msgid不一樣？msgid檢查是否是事務(wù)消息或延時(shí)消息，如果是，則是正?，F(xiàn)象。需要做冪等的話可以使用消息ey來做冪等。事務(wù)消息或延時(shí)消息訂閱方的msgid取的是tnaiI。通過message.getMsgID()這個(gè)獲取的transactionId在控制臺(tái)上是查不到消息的，這時(shí)候可以通過message.getUserProperties().getProper-ty("UNIQ_KEY")這個(gè)來獲取真正的msgid。因?yàn)槟承﹕dk的原因，有可能發(fā)送方和訂閱方的msgid也會(huì)不一樣。任何類型的消息都是這樣，這時(shí)訂閱方的msgid是d。這個(gè)很好區(qū)分，transactionId，msgidoffsetmsgid字首先確認(rèn)在MQ控制臺(tái)已經(jīng)創(chuàng)建了GID此時(shí)重點(diǎn)檢查實(shí)例化消費(fèi)者參數(shù)時(shí)NAMESRV_ADDR參數(shù)配置是否與步驟：刪除客戶端日志>重啟應(yīng)用>查看的ons.log同時(shí)確認(rèn)NameServer是可連接的，net控制臺(tái)提供的接入點(diǎn)看下是ackmessage錯(cuò)NumberofreceiptHandlesinXMLisoutofrangehttp協(xié)議的MQackmessage時(shí)返回了message:NumberofreceiptHandlesinXMLisoutofrange一次最多是16個(gè)，超過就會(huì)報(bào)錯(cuò)了。啟動(dòng)消費(fèi)端提示GroupID重復(fù)啟動(dòng)消息隊(duì)列MQ版的Producer（生產(chǎn)者）實(shí)例或Consumer（消費(fèi)者）實(shí)例時(shí)，提示GroupID重復(fù)。單個(gè)JVM進(jìn)程中出現(xiàn)下列情況時(shí)，會(huì)導(dǎo)致客戶端啟動(dòng)失敗，提示GroupID重ProducerGroupID。啟動(dòng)了一個(gè)以上的Consumer實(shí)例，并且這些實(shí)例使用相同的GroupID。啟動(dòng)了一個(gè)以上的Producer實(shí)例和一個(gè)以上的Cnsuer實(shí)例，并且這些實(shí)GroupID。JVMGroupIDProducerConsumer0個(gè)1個(gè)以1個(gè)以消費(fèi)者啟動(dòng)時(shí)提示獲取Topic隊(duì)列失敗消息隊(duì)列MQ版中Consume消費(fèi)者）主動(dòng)訂閱消息，啟動(dòng)客戶端時(shí)導(dǎo)致此問題的主要原因是客戶端中訂閱的Topic未在消息隊(duì)列MQ版的控登錄消息隊(duì)列MQ版的控制臺(tái)，創(chuàng)建Topic和GroupID更新客戶端中訂閱的Topic和u，確保其與控制臺(tái)中創(chuàng)建的信息在/{user.home}/logs/ons.logOutOfMemory在消息隊(duì)列MQ版控制臺(tái)：進(jìn)入消費(fèi)者管理>消費(fèi)者狀態(tài)，堆積量過Jstack排查，ConsumeMessageThread_線程無消費(fèi)卡住現(xiàn)象。在1.7.0.Final版本之前，默認(rèn)客戶端最多會(huì)給每個(gè)Topic的每個(gè)隊(duì)列緩存?zhèn)€隊(duì)列）Topic64KB，TopicSize：16*1000*64KB1GB8Topic戶端內(nèi)存緩存消息，最終占用內(nèi)存將超過用戶的JVM配置，導(dǎo)致OOM。依賴1.7.0.Final之前的ons-版本，Topic的平均消息大小超過4KB，升級(jí)ons-版本至1.7.0.Final或以上，同時(shí)給對(duì)應(yīng)的配合設(shè)置原因2：MGroupID訂閱的所有Topic緩存總和）；如果應(yīng)用仍然出現(xiàn)OOMConsumer-Bean啟動(dòng)時(shí)，配置：cmaiyunoenervce.on.iPoetKyCntaxhees-確認(rèn)應(yīng)用依賴的ons-版本，并通過JVM確認(rèn)給進(jìn)程分配的內(nèi)存大小。根據(jù)應(yīng)用機(jī)器的內(nèi)存使用清況給對(duì)應(yīng)的ConsumerBeanopenservices.ons.api.PropertyKeyConst#MaxCachedMessageSizeInMiB參異常：consumeThreadMaxOutofrange[1,異常：messageListeneris異常：consumerGroupisGroup描述：定時(shí)消息延時(shí)過40天消息顯示_Consumed_,但消費(fèi)端未感知到消息狀態(tài)顯示“ConsumedmessageId,timestamp,recons-umeTime等。到消息隊(duì)列MQ版控制臺(tái)，進(jìn)入Group管理>消費(fèi)者狀態(tài)>連接狀態(tài)，使用的是批量消費(fèi)的apiBtchCnsumr，為何每次消費(fèi)的消息都是一條或者不是我設(shè)置的屬性PropertyKeyConst.ConsumeMessageBataxSize的值？不能做到每次消費(fèi)的消息是一個(gè)固定值。PropertyKeyConst.ConsumeMessage-BataxSize取值范圍為1-32。建議您業(yè)務(wù)邏輯放在返回給mq服務(wù)端的代碼之前，最好是保證盡快給到mq響應(yīng)。這樣可以避免消息消費(fèi)失敗，在進(jìn)行消息重試。如果您的業(yè)務(wù)邏輯時(shí)間的確很長，建議您可以將信息拉取到之后，存到數(shù)據(jù)庫、rdis當(dāng)中，然后盡快給到mq查看發(fā)送端或消費(fèi)端啟動(dòng)時(shí)，將PropertyKeyConst.MsgTraceSwitch間段的ons.log,檢查日志中是否有：sendtracedata,thetraceDataisSubAfter的消息無法到的情況。所以會(huì)看到上面的問題。后面我們會(huì)繼續(xù)優(yōu)化。點(diǎn)到指定開始時(shí)間點(diǎn)。消費(fèi)程序調(diào)用OpenAPI查詢軌跡信息： 注意一點(diǎn)，OpenAPIdbcommitbroker，但是軌這個(gè)耗時(shí)的時(shí)間是調(diào)用發(fā)送消息的com.aliyun.open alibaba.mq..impl.MQAPIImpl#sendMessage()的耗時(shí)時(shí)間。如果是同步發(fā)送，則會(huì)包含到broker的時(shí)間，異步和oneWay則不包含。發(fā)送端的代碼邏輯可以看 consme()的整個(gè)花費(fèi)的時(shí)間。也就是圖2的SubAfter的TimeStamp減去SubBefore的TimeStamp的時(shí)間。ConsumeMessageConcurrentlyService.ConsumeRequest#run()（邏輯）中執(zhí)行的利用ipconfig查看。ipipiiecsdocker，mqIpdockerip，ecsipipip實(shí)例詳情--數(shù)據(jù)統(tǒng)計(jì)當(dāng)中的消息堆積量是有一定延遲的，是采樣數(shù)據(jù)，不是實(shí)能會(huì)是之前的歷史數(shù)據(jù)，具體的還是要以group管理當(dāng)中的實(shí)時(shí)消息堆積量為準(zhǔn)。為什么實(shí)例下沒有該topic，創(chuàng)建的時(shí)候卻提示該topic已存在topic的時(shí)候，該實(shí)例下不存在新建的ctopic已gidtopic(topic，消費(fèi)者狀態(tài)連接信息的客戶端ID，公網(wǎng)IPdpx境利用iconfig查看，使用的是NetworkInterface.getNetworkInterfaces()ifconfig.me或curlcip.cc查看，windows環(huán)境直接搜索ip查看。資源報(bào)表當(dāng)中類型的tps是什么意是TransactionsPerSecond的縮寫，也就是每秒處理的事務(wù)數(shù)。MQ中主要用來表示某個(gè)topic的每秒鐘生產(chǎn)了多少消息數(shù)量或某個(gè)消費(fèi)組每秒消費(fèi)了多少消息數(shù)為什么控制臺(tái)查看不到pid了RokcetMQpidpid如果不想代碼當(dāng)中有messageProducerId配置，建議將sdk升級(jí)到版topicpidgid如果后續(xù)新建實(shí)例，有命名空間的，接入點(diǎn)配置項(xiàng)需要變化，代碼中的SAddrNAMESRV_ADDR間-最開始堆積的那條消息的時(shí)間。告警相關(guān)問Mq的只能有創(chuàng)建該的賬號(hào)登陸才能查看，主賬號(hào)以及其他賬 Api計(jì)費(fèi)標(biāo)準(zhǔn)API請(qǐng)求次數(shù)=發(fā)送消息API請(qǐng)求次數(shù)+訂閱消息API請(qǐng)求次數(shù)+長輪詢長輪詢就是說針對(duì)每一個(gè)隊(duì)列（queue）15i當(dāng)中是否有可見的需要消費(fèi)的消息。每一次拉取都算是一次調(diào)用api，都會(huì)收取費(fèi)所以一個(gè)topic下面有3個(gè)broker，每個(gè)broker有8個(gè)隊(duì)列，如果該i當(dāng)中一整天都沒有消息進(jìn)來，那么一天就是24*24*60*4次調(diào)用。所以建議如隊(duì)列queue個(gè)數(shù)是本身實(shí)例決定的，這個(gè)目前不支持用戶側(cè)配置Topic底層對(duì)應(yīng)的queue數(shù)目。并且不支持修改queue的個(gè)數(shù)。標(biāo)準(zhǔn)版實(shí)例tps用量限制直接鉑，因?yàn)槿绻跇?biāo)準(zhǔn)版實(shí)例的基礎(chǔ)上申請(qǐng)調(diào)大tps，可能花費(fèi)的金額會(huì)答：消息隊(duì)列MQ版費(fèi)用=API調(diào)用費(fèi)+Topic資源占用費(fèi)。每Topic2答：Topic資源占用費(fèi)以每天00:00-23:59:59為周期進(jìn)行計(jì)費(fèi)，第二天收費(fèi)。所以，昨天刪除c，昨天的計(jì)費(fèi)系統(tǒng)已經(jīng)計(jì)入，今天會(huì)出賬單問：我沒有使用消息隊(duì)列MQ版服務(wù)，為什么會(huì)扣費(fèi)答：請(qǐng)查看賬單，檢查您是否有使用消息隊(duì)列MQ版服務(wù)如果您不需要使用消息隊(duì)列MQ版服務(wù)，請(qǐng)及時(shí)刪除消息隊(duì)問：我有看到消息隊(duì)列MQ版的扣費(fèi)，但是我在控制臺(tái)上看到?jīng)]有答：消息隊(duì)列MQ版處于欠費(fèi)狀態(tài)超過72小時(shí)，阿將暫停為您提供服務(wù)，即您不能再消息隊(duì)列MQ版控制臺(tái)與消息隊(duì)列MQ版API。但是您的消息隊(duì)列MQ版服務(wù)被釋放之前問：如何關(guān)閉消息隊(duì)列MQ版服務(wù)631,238API數(shù)為126,315,056次，那么多API調(diào)用次數(shù)怎么來的？答：APIAPIAPI輪詢API調(diào)用次數(shù)（長輪詢說明：消息隊(duì)列MQ版Consumer為保證消息實(shí)時(shí)推送而產(chǎn)生的API調(diào)用，每個(gè)隊(duì)列15秒一次長輪詢，如何查看整個(gè)實(shí)例的tps以及總用tps。topc條消息的字節(jié)數(shù)就可以算出一天的大小。升級(jí)c++版本到2.0csdk升級(jí)到2.0后日志過多，甚至導(dǎo)致開發(fā)環(huán)境磁盤100%，這個(gè)怎么Ons.log: eCumeOToBkMessageQueueopc=XXXXbrokerName=qdnternetorder-02MessageQueue里包括了消息、對(duì)應(yīng)的brokerName,消費(fèi)隊(duì)列的id。HeartbeatData ID=XXX,ProducerData[groupName=XXXX],ProducerData[groupName=XXX]],consumerDataSet=[]]sendheartbeattobroker[XX]success說明：該現(xiàn)象是向服務(wù)端發(fā)送心跳包成功Harteatata是心跳相關(guān)的信息，id、發(fā)送組信息、消費(fèi)組信息。[PULL_TPS][CID_XXXX@CID_XXXX]StatsInOneMnute,SUM:0TPS:0.00AVGPT:0.00[PULLT]%RETRY%CDXXXX@D_X]StatsInOneMnute,SUM:0TPS:0.00AVGPT:IMEOU_CLEAN_QUEUEbokebusy,startocontrolforawheperonqueue:905mssizeofqueue:1164說明：服務(wù)端壓力過大、處理不了過多的請(qǐng)求；由于mq服務(wù)端在數(shù)據(jù)時(shí)是先寫入aa然后去刷盤、因此每隔10s會(huì)去清理過期的請(qǐng)求解決方案broker executethepullrequest CODE:25DESC:theconsumer'ssubscrptionnot說明：1.updateConsumeOffsetToBroker日志是正常的，是一個(gè)定時(shí)任務(wù)，定期同步offsetBroker。2.theconsumer'ssubscriptionnotlatest的"Consumer制：當(dāng)一個(gè)新的consmerqueue以實(shí)現(xiàn)負(fù)載均衡，此時(shí)會(huì)短暫的pull請(qǐng)求，直到該cnsumer被重新分配了queue。[WRONG]mqisconsuming,socannotunlockit,MessageQueue[topic=XX,Name=szorder2-02,queueId=1].maybehangedforawhle,doRebalance,XXX-CID,addanewmqfailed,MessageQueue[topic=XXXX,Name=szorder2-02,queueId=5],becauselock說明：用戶使用的是順序Topic，為了保證單個(gè)分區(qū)中消息的順序消費(fèi)，這個(gè)會(huì)有個(gè)lock的機(jī)制?？蛻舳擞羞@個(gè)日志說明其中某個(gè)分區(qū)已經(jīng)有客戶端在getTopic[XXXXXX]RouteInfoFromNameServerisnotexist .alibaba.mq..exception.MQException:17DESC:Notopicrouteinfonnameserverforthetopic:TOPIC_XXXXXSeeforfurtherdetails.說明：nameServernameServertopicList實(shí)例化的代碼中，NameServerAddr用mqadmintopicRoute可排查路由信息com.aliyun.openservices.ons.api.impl.authority.exception.AuthenticationException:signaturevalidatebydauthfailed解決方案：AK/SK要配置創(chuàng)建該GID使用的AK/SKNettyPublicExecutor_3-executethepullrequest CODE:26DESC:subscriptiongroup[CID_XXX]doesnotexist,SeefurtherMQexecutethepullrequest CODE:24DESC:theconsumer'ssubscrptionnotsendKernelImplexception,resendatonceInvokeID:- 5,RT:7183ms,Broker:MessageQueue[topic=xxxx,brokerName=xxx,queueId=2] .albaba.mqremoootuception:waitresponseonthechannel<xx.xxx.xxx.xx:8080>timeout,5000(ms)MQdecodeexception,在4kb之內(nèi)。systemmqtracehookintfaled,maybecan'tsendmsgtrace解決方案：通過設(shè)置MsgTraceSwitch,String.valueOf(false))。nsumeOeBexeponMessageQueue[topic=xxxx,brokerName=xxxx,queueId=1]omalyun.ope .MQception:Thebroker[xxxx]notexistFormorenformation升級(jí)期間可能會(huì)出現(xiàn)此異常。MQ是集群部署，一臺(tái)發(fā)送失