分析：這個(gè)問題其實(shí)換一種問法就是，如何保證消息隊(duì)列的冪等性？這個(gè)問題可以認(rèn)為是消息隊(duì)列領(lǐng)域的基本問題。換句話來說，是在考察你的設(shè)計(jì)能力，這個(gè)問題的回答可以根據(jù)具體的業(yè)務(wù)場(chǎng)景來答，沒有固定的答案。

?

?

回答：先來說一下為什么會(huì)造成重復(fù)消費(fèi)？
其實(shí)無(wú)論是哪種消息隊(duì)列，造成重復(fù)消費(fèi)原因其實(shí)都是類似的。正常情況下，消費(fèi)者在消費(fèi)消息的時(shí)候，消費(fèi)完畢后，會(huì)發(fā)送一個(gè)確認(rèn)消息給消息隊(duì)列，消息隊(duì)列就知道該消息被消費(fèi)了，就會(huì)將該消息從消息隊(duì)列中刪除。只是不同的消息隊(duì)列發(fā)出的確認(rèn)消息形式不同，例如RabbitMQ是發(fā)送一個(gè)ACK確認(rèn)消息，RocketMQ是返回一個(gè)CONSUME_SUCCESS成功標(biāo)志，kafka實(shí)際上有個(gè)offet的概念，簡(jiǎn)單說一下，就是每一個(gè)消息都有一個(gè)offset，kafka消費(fèi)過消息后，需要提交offset，讓消息隊(duì)列知道自己已經(jīng)消費(fèi)過了。

那造成重復(fù)消費(fèi)的原因？，就是因?yàn)榫W(wǎng)絡(luò)傳輸?shù)鹊裙收?#xff0c;確認(rèn)信息沒有傳送到消息隊(duì)列，導(dǎo)致消息隊(duì)列不知道自己已經(jīng)消費(fèi)過該消息了，再次將消息分發(fā)給其他的消費(fèi)者。

其實(shí)重復(fù)消費(fèi)不可怕，可怕的是你沒考慮到重復(fù)消費(fèi)之后，怎么保證冪等性。 ?

假設(shè)你有個(gè)系統(tǒng)，消費(fèi)一條往數(shù)據(jù)庫(kù)里插入一條，要是你一個(gè)消息重復(fù)兩次，你不就插入了兩條，這數(shù)據(jù)不就錯(cuò)了？但是你要是消費(fèi)到第二次的時(shí)候，自己判斷一下已經(jīng)消費(fèi)過了，直接扔了，不就保留了一條數(shù)據(jù)？ ? 一條數(shù)據(jù)重復(fù)出現(xiàn)兩次，數(shù)據(jù)庫(kù)里就只有一條數(shù)據(jù)，這就保證了系統(tǒng)的冪等性 ? 冪等性，我通俗點(diǎn)說，就一個(gè)數(shù)據(jù)，或者一個(gè)請(qǐng)求，給你重復(fù)來多次，你得確保對(duì)應(yīng)的數(shù)據(jù)是不會(huì)改變的，不能出錯(cuò)。

如何解決？這個(gè)問題針對(duì)業(yè)務(wù)場(chǎng)景來答，分以下三種情況：

（1）比如，你拿到這個(gè)消息做數(shù)據(jù)庫(kù)的insert操作，那就容易了，給這個(gè)消息做一個(gè)唯一的主鍵，那么就算出現(xiàn)重復(fù)消費(fèi)的情況，就會(huì)導(dǎo)致主鍵沖突，避免數(shù)據(jù)庫(kù)出現(xiàn)臟數(shù)據(jù)。

（2）再比如，你拿到這個(gè)消息做redis的set的操作，那就容易了，不用解決，因?yàn)槟銦o(wú)論set幾次結(jié)果都是一樣的，set操作本來就算冪等操作。

（3）如果上面兩種情況還不行，上大招。準(zhǔn)備一個(gè)第三方介質(zhì)，來做消費(fèi)記錄。以redis為例，給消息分配一個(gè)全局id，只要消費(fèi)過該消息，將<id,message>以K-V形式寫入redis.那消費(fèi)者開始消費(fèi)前，先去redis中查詢有沒有消費(fèi)記錄即可,先根據(jù)這個(gè)id去比如redis里查一下，之前消費(fèi)過嗎？如果沒有消費(fèi)過，你就處理，然后這個(gè)id寫redis。如果消費(fèi)過了，那你就別處理了，保證別重復(fù)處理相同的消息即可。

總結(jié)

以上是生活随笔為你收集整理的如何保证消息不被重复消费~~~~~(如何保证消息队列的幂等性)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。