高級Activemq面試題及答案：

具體哪些情況下會引起消息重發?

1.client用了transaction且再session中調用了rouback()

2.client用了transaction且再調用了commit()之前關閉或者沒有commit

3.client再client-ACKNOMEDGE的傳遞模式下，在session中調用了recaver()

請說說消息重發時間間隔和重發次數?

間隔：1

次數：6

有毒消息poison ACK 談談你的理解

一個消息被redelivedred超過默認的最大重發次數(默認次數是6)時，消費端會給MQ發送一個“poison ack” 表示這個消息有毒，告訴broker不要再發了，這個時候broker會把這個消息放到DLQ(死信隊列)

死信隊列?

ActiveMQ中引入了 死信隊列 的概念，即一條消息再被重發多次后(默認是6)

將會被ActiveMQ移入死信隊列，程序員 也就是我們可以在這個Queue中查看處理出錯的消息，進行人工干預。

死信隊列的使用：處理失敗的消息

一般生產環境中，使用MQ的時候，設計兩個隊列：一個核心隊列，一個死信隊列

核心業務隊列就是比如用訂單系統發送訂單消息，然后另外一個死信隊列用來處理異常的情況。

假如第三方物流系統故障了，此時無法請求，那么倉儲系統每次消費到一條訂單消息，嘗試通知發貨和配送都會遇到對方的接口報錯。此時倉儲系統就可以把這條消息拒絕訪問或者標志為處理失敗。一旦標志這條消息處理失敗后，MQ就會把這條消息轉入提前設置好的一個死信隊列中，然后你會看到的就是在第三方的物流系統故障期間，所以訂單消息全部處理失敗，全部轉入死信隊列，然后你的倉儲系統得到專門有一個后臺線程監控第三方物流系統是否正常運行，能否請求到，不停的監控，一旦發現對方恢復正常，這個后臺線程就可以從死信隊列消費出來 處理失敗的訂單，重新執行發貨和配送的通知邏輯

如何保障消息不被重復消費呢?冪等性問題等等

網絡延遲傳輸，會造成ActiveMQ重試中，在重試過程中，可能會造成重復消費

如果消息是做數據庫插入操作;給這個消息做一個唯一主鍵，那么就算出現重復消費，就導致主鍵沖突，避免出現臟數據

如果上述面兩種情況還是不行，準備一個第三方服務來做消費記錄，以redis為例，給消息分配一個全局ID，只要消費國這個消息，將 以K-V的形式寫入redis，那么消費者開始消費前，先去redis中直接查詢有沒有消費記錄即可