本篇內(nèi)容介紹了“activemq死信隊(duì)列的消息處理方法是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比秀峰網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式秀峰網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋秀峰地區(qū)。費(fèi)用合理售后完善，10年實(shí)體公司更值得信賴。
1.死信隊(duì)列出現(xiàn)的原因
跟預(yù)想的什么事務(wù)啊，重試啊，宕機(jī)啊沒(méi)dei關(guān)系
Cannot display ObjectMessage body. Reason: Failed to build body from content. Serializable class not available to broker. Reason: java.lang.ClassNotFoundException: xxx
應(yīng)該是處理此條消息的時(shí)候，實(shí)體類未序列化？然后我重試下，將實(shí)體類序列化去掉，這在運(yùn)行時(shí)會(huì)直接異常的，目前原因不詳。
2.如何處理死信隊(duì)列中的消息？
這個(gè)監(jiān)聽的思路是對(duì)的，就是實(shí)施有點(diǎn)問(wèn)題，總是監(jiān)聽不到
1:人工處理(太累)
2:定時(shí)任務(wù)(太耗性能)
3:監(jiān)聽死信隊(duì)列
4:死信隊(duì)列寫庫(kù)
另外處理消息時(shí)，會(huì)發(fā)生與預(yù)想結(jié)果不一致，業(yè)務(wù)是點(diǎn)贊/取消點(diǎn)贊，如果原本目的是取消點(diǎn)贊，但操作失敗redis是有的，進(jìn)入死信隊(duì)列數(shù)據(jù)庫(kù)是沒(méi)數(shù)據(jù)的，我在此期間對(duì)這條數(shù)據(jù)進(jìn)行了點(diǎn)贊，然后又取消了，那如果此時(shí)我處理這條消息，會(huì)進(jìn)行點(diǎn)贊，與原本的目的不一致
3.監(jiān)聽+時(shí)間
創(chuàng)建一個(gè)監(jiān)聽器，監(jiān)聽死信隊(duì)列ActiveMQ.DLQ隊(duì)列是否有消息，有消息就進(jìn)行消費(fèi)。每次mq入隊(duì)前標(biāo)識(shí)一個(gè)時(shí)間戳，取出死信隊(duì)列的消息，與當(dāng)前庫(kù)里的操作時(shí)間對(duì)比，如果最后一條記錄的時(shí)間大于此條消息時(shí)間不予處理，否則進(jìn)行消息補(bǔ)償。redis+mq+MySQL進(jìn)行數(shù)據(jù)同步時(shí)同理
4.redis+mq并發(fā)1萬(wàn)會(huì)產(chǎn)生消息積壓?jiǎn)幔?/strong>
不會(huì)，產(chǎn)生積壓的原因是業(yè)務(wù)系統(tǒng)不再監(jiān)控某隊(duì)列，即便是1萬(wàn)并發(fā)同事請(qǐng)求，肯定會(huì)發(fā)生隊(duì)列排隊(duì)消費(fèi)，但不會(huì)發(fā)生積壓，另外如出現(xiàn)此情況，需要短信報(bào)警，并手動(dòng)刪除或腳本刪除此隊(duì)列。
最高等待隊(duì)列數(shù)
5.一個(gè)業(yè)務(wù)一個(gè)隊(duì)列，無(wú)用隊(duì)列怎么處理？
目前接觸的業(yè)務(wù)，每個(gè)業(yè)務(wù)都需要自定義隊(duì)列名，有的隊(duì)列等待，有的始終沒(méi)處理業(yè)務(wù)，此時(shí)可自定義關(guān)閉監(jiān)測(cè)時(shí)間內(nèi)不工作的隊(duì)列，如需要時(shí)再開啟，以此減少其他隊(duì)列的壓力。
配置可看下activemq.xml的47行
constantPendingMessageLimitStrategy用于防止慢話題消費(fèi)者阻礙生產(chǎn)者和影響其他消費(fèi)者通過(guò)限制保留的消息數(shù)
重慶分公司
重慶分公司
