溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“activemq死信隊列的消息處理方法是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
1.死信隊列出現的原因
跟預想的什么事務啊，重試啊，宕機啊沒dei關系
Cannot display ObjectMessage body. Reason: Failed to build body from content. Serializable class not available to broker. Reason: java.lang.ClassNotFoundException: xxx
應該是處理此條消息的時候，實體類未序列化？然后我重試下，將實體類序列化去掉，這在運行時會直接異常的，目前原因不詳。
2.如何處理死信隊列中的消息？
這個監聽的思路是對的，就是實施有點問題，總是監聽不到
1:人工處理(太累)
2:定時任務(太耗性能)
3:監聽死信隊列
4:死信隊列寫庫
另外處理消息時，會發生與預想結果不一致，業務是點贊/取消點贊，如果原本目的是取消點贊，但操作失敗redis是有的，進入死信隊列數據庫是沒數據的，我在此期間對這條數據進行了點贊，然后又取消了，那如果此時我處理這條消息，會進行點贊，與原本的目的不一致
3.監聽+時間
創建一個監聽器，監聽死信隊列ActiveMQ.DLQ隊列是否有消息，有消息就進行消費。每次mq入隊前標識一個時間戳，取出死信隊列的消息，與當前庫里的操作時間對比，如果最后一條記錄的時間大于此條消息時間不予處理，否則進行消息補償。redis+mq+mysql進行數據同步時同理
4.redis+mq并發1萬會產生消息積壓嗎？
不會，產生積壓的原因是業務系統不再監控某隊列，即便是1萬并發同事請求，肯定會發生隊列排隊消費，但不會發生積壓，另外如出現此情況，需要短信報警，并手動刪除或腳本刪除此隊列。
最高等待隊列數
5.一個業務一個隊列，無用隊列怎么處理？
目前接觸的業務，每個業務都需要自定義隊列名，有的隊列等待，有的始終沒處理業務，此時可自定義關閉監測時間內不工作的隊列，如需要時再開啟，以此減少其他隊列的壓力。
配置可看下activemq.xml的47行
constantPendingMessageLimitStrategy用于防止慢話題消費者阻礙生產者和影響其他消費者通過限制保留的消息數<destinationPolicy><policyMap><policyEntries><policyEntry topic=">" ><!-- The constantPendingMessageLimitStrategy is used to preventslow topic consumers to block producers and affect other consumersby limiting the number of messages that are retainedFor more information, see:http://activemq.apache.org/slow-consumer-handling.html--><pendingMessageLimitStrategy><constantPendingMessageLimitStrategy limit="1000"/></pendingMessageLimitStrategy></policyEntry></policyEntries></policyMap>
<!-- 在這里加上schedulePeriodForDestinationPurge屬性。--><broker xmlns="http://activemq.apache.org/schema/core" schedulePeriodForDestinationPurge="10000" <destinationPolicy> <policyMap> <policyEntries> <!-- 在這里加上gcInactiveDestinations和inactiveTimoutBeforeGC兩個屬性 --> <policyEntry queue=">" gcInactiveDestinations="true" inactiveTimoutBeforeGC="30000"/> </policyEntries> </policyMap> </destinationPolicy></broker>
6.為什么預想3萬次的任務執行，結果不一致？
為了測試業務是否會出現頻繁取消確認出現不一致的情況，單接口一萬次，測了3次，目前一共執行了3次，第一次告8552，第二次，第三次是成功的，按理說一共是28552次，但結果是28527，理想是3萬次，在jmeter的結果樹種分析無錯誤日志
原因不曉得。勾選Scroll無用。
這個隊列加時間跟
如何解決redis的并發競爭key問題相似，處理方案也是相似
“activemq死信隊列的消息處理方法是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
