今天這是MQ消息消費必問面試的第三個問題，重復(fù)消費。如果你還沒有看消息丟失、消息堆積，可以先去點擊鏈接進行查看。

面試官：對于MQ中的消息丟失你是如何理解的?

面試官：對于MQ中的消息堆積你是怎么理解的?

首先我們先看一下消息重復(fù)消費的定義，就是字面意思，一條消息被消費執(zhí)行了多次?？梢允且粋€消費者消費了多次，也可以是多個消費者消費了同一條消息。

一、重復(fù)消費消息對系統(tǒng)的影響

消息重復(fù)消費可能導(dǎo)致數(shù)據(jù)在數(shù)據(jù)庫中被重復(fù)插入，這其實還好，重復(fù)插入只要不是影響業(yè)務(wù)，在查詢時去重也可以解決，俗稱治標(biāo)不治本。

如果是通知類消息，用戶可能會收到多條通知，對于用戶的體驗會有所影響。

但是消息的重復(fù)消費最壞的就是導(dǎo)致數(shù)據(jù)的不一致，如果是訂單類的系統(tǒng)，多次消費帶來的不一致可能是致命的錯誤，例如多次扣款、超賣等。

消息重復(fù)消費在系統(tǒng)高并發(fā)的時候會嚴重的影響系統(tǒng)性能，消費者吞吐量下降造成消息堆積等。

二、消息發(fā)生重復(fù)消費的原因

消息重復(fù)消費產(chǎn)生的原因有很多，比如上一篇文章消息堆積中產(chǎn)生消息堆積的原因之一，消費者異常多次重試消費。

• 消費者在消費消息的過程中，業(yè)務(wù)代碼異常一直重試，沒有對異常行為進行控制造成單條消息卡住，一直重復(fù)消費。
• 消費者應(yīng)答機制不合理，在消費者處理完業(yè)務(wù)之后無法正常應(yīng)答或者因網(wǎng)絡(luò)原因應(yīng)答失敗。
• 配置錯誤，手動ack，消費者消費完成之后沒有成功ack。

三、消息重復(fù)消費解決方案

• 合理配置應(yīng)答機制，手動應(yīng)答，消費者業(yè)務(wù)處理盡量簡單，對各種異常做好處理，增強應(yīng)用系統(tǒng)健壯性。
• 消息重試次數(shù)增加限制，防止消息一直重試。
• MQ中配置合理的消息語義，保證至少一次，然后業(yè)務(wù)端做好去重。
• 增加消息唯一標(biāo)識，消費過的消息不在進行處理。
• 消費端業(yè)務(wù)邏輯處理冪等，保證不管消費多少次都與消費一次的結(jié)果相同。
• 使用死信隊列，當(dāng)消息一直重復(fù)消費時加入死信隊列。
• 監(jiān)控，發(fā)現(xiàn)異常消息消費及時告警。

總結(jié)

消息重復(fù)產(chǎn)生的原因可以概括為兩點，應(yīng)答失敗與業(yè)務(wù)異常循環(huán)消費單條消息。

對于消息的重復(fù)消費，業(yè)界用的最多的，還是消息唯一標(biāo)識加冪等。消費端代碼盡可能的對異常情況做好處理，保證在發(fā)生異常之后可以正確的應(yīng)答。

對于消息唯一標(biāo)識這里簡單說兩句，可以生產(chǎn)者加入消息唯一標(biāo)識，消費者也加入唯一標(biāo)識，生產(chǎn)者與消費者不必相同，保證消息唯一即可。

在消費者進行消費消息時，首先根據(jù)消息唯一標(biāo)識判斷是否已經(jīng)消費過，可以使用 Redis 或者 MySQL 中的唯一索引等方式，然后來判斷該消息是否可以被消費。