高級(jí)Activemq面試題及答案：

具體哪些情況下會(huì)引起消息重發(fā)?

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

2.client用了transaction且再調(diào)用了commit()之前關(guān)閉或者沒有commit

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

請(qǐng)說(shuō)說(shuō)消息重發(fā)時(shí)間間隔和重發(fā)次數(shù)?

間隔：1

次數(shù)：6

有毒消息poison ACK 談?wù)勀愕睦斫?/h2>

一個(gè)消息被redelivedred超過(guò)默認(rèn)的最大重發(fā)次數(shù)(默認(rèn)次數(shù)是6)時(shí)，消費(fèi)端會(huì)給MQ發(fā)送一個(gè)“poison ack” 表示這個(gè)消息有毒，告訴broker不要再發(fā)了，這個(gè)時(shí)候broker會(huì)把這個(gè)消息放到DLQ(死信隊(duì)列)

死信隊(duì)列?

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

將會(huì)被ActiveMQ移入死信隊(duì)列，程序員 也就是我們可以在這個(gè)Queue中查看處理出錯(cuò)的消息，進(jìn)行人工干預(yù)。

死信隊(duì)列的使用：處理失敗的消息

一般生產(chǎn)環(huán)境中，使用MQ的時(shí)候，設(shè)計(jì)兩個(gè)隊(duì)列：一個(gè)核心隊(duì)列，一個(gè)死信隊(duì)列

核心業(yè)務(wù)隊(duì)列就是比如用訂單系統(tǒng)發(fā)送訂單消息，然后另外一個(gè)死信隊(duì)列用來(lái)處理異常的情況。

假如第三方物流系統(tǒng)故障了，此時(shí)無(wú)法請(qǐng)求，那么倉(cāng)儲(chǔ)系統(tǒng)每次消費(fèi)到一條訂單消息，嘗試通知發(fā)貨和配送都會(huì)遇到對(duì)方的接口報(bào)錯(cuò)。此時(shí)倉(cāng)儲(chǔ)系統(tǒng)就可以把這條消息拒絕訪問(wèn)或者標(biāo)志為處理失敗。一旦標(biāo)志這條消息處理失敗后，MQ就會(huì)把這條消息轉(zhuǎn)入提前設(shè)置好的一個(gè)死信隊(duì)列中，然后你會(huì)看到的就是在第三方的物流系統(tǒng)故障期間，所以訂單消息全部處理失敗，全部轉(zhuǎn)入死信隊(duì)列，然后你的倉(cāng)儲(chǔ)系統(tǒng)得到專門有一個(gè)后臺(tái)線程監(jiān)控第三方物流系統(tǒng)是否正常運(yùn)行，能否請(qǐng)求到，不停的監(jiān)控，一旦發(fā)現(xiàn)對(duì)方恢復(fù)正常，這個(gè)后臺(tái)線程就可以從死信隊(duì)列消費(fèi)出來(lái) 處理失敗的訂單，重新執(zhí)行發(fā)貨和配送的通知邏輯

如何保障消息不被重復(fù)消費(fèi)呢?冪等性問(wèn)題等等

網(wǎng)絡(luò)延遲傳輸，會(huì)造成ActiveMQ重試中，在重試過(guò)程中，可能會(huì)造成重復(fù)消費(fèi)

如果消息是做數(shù)據(jù)庫(kù)插入操作;給這個(gè)消息做一個(gè)唯一主鍵，那么就算出現(xiàn)重復(fù)消費(fèi)，就導(dǎo)致主鍵沖突，避免出現(xiàn)臟數(shù)據(jù)

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