1、面試題

如何保證消息不被重復消費啊（如何保證消息消費時的冪等性）？

2、面試官心里分析

其實這個很常見的一個問題，這倆問題基本可以連起來問。既然是消費消息，那肯定要考慮考慮會不會重復消費？能不能避免重復消費？或者重復消費了也別造成系統(tǒng)異?？梢詥?#xff1f;這個是MQ領域的基本問題，其實本質上還是問你使用消息隊列如何保證冪等性，這個是你架構里要考慮的一個問題。
面試官問你，肯定是必問的，這是你要考慮的實際生產上的系統(tǒng)設計問題。

3、面試題剖析

回答這個問題，首先你別聽到重復消息這個事兒，就一無所知吧，你先大概說一說可能會有哪些重復消費的問題。
首先就是比如rabbitmq、rocketmq、kafka，都有可能會出現(xiàn)消費重復消費的問題，正常。因為這問題通常不是mq自己保證的，是給你保證的。然后我們挑一個kafka來舉個例子，說說怎么重復消費吧。

?

Kafka實際上有個offset的概念，就是每個消息寫進去，都有一個offset，代表它的序號，然后consumer消費了數(shù)據(jù)之后，每隔一段時間，會把自己消費過的消息的offset提交一下，代表我已經(jīng)消費過了，下次我要是重啟啥的，你就讓我繼續(xù)從上次消費到的offset來繼續(xù)消費吧。

但是凡事總有意外，比如我們之前生產經(jīng)常遇到的，就是你有時候重啟系統(tǒng)，看你怎么重啟了，如果碰到點著急的，直接kill進程了，再重啟。這會導致consumer有些消息處理了，但是沒來得及提交offset，尷尬了。重啟之后，少數(shù)消息會再次消費一次。

其實重復消費不可怕，可怕的是你沒考慮到重復消費之后，怎么保證冪等性。

給你舉個例子吧。假設你有個系統(tǒng)，消費一條往數(shù)據(jù)庫里插入一條，要是你一個消息重復兩次，你不就插入了兩條，這數(shù)據(jù)不就錯了？但是你要是消費到第二次的時候，自己判斷一下已經(jīng)消費過了，直接扔了，不就保留了一條數(shù)據(jù)？

一條數(shù)據(jù)重復出現(xiàn)兩次，數(shù)據(jù)庫里就只有一條數(shù)據(jù)，這就保證了系統(tǒng)的冪等性

冪等性，我通俗點說，就一個數(shù)據(jù)，或者一個請求，給你重復來多次，你得確保對應的數(shù)據(jù)是不會改變的，不能出錯。

那所以第二個問題來了，怎么保證消息隊列消費的冪等性？

?

其實還是得結合業(yè)務來思考，我這里給幾個思路：

比如你拿個數(shù)據(jù)要寫庫，你先根據(jù)主鍵查一下，如果這數(shù)據(jù)都有了，你就別插入了，update一下好吧。

比如你是寫redis，那沒問題了，反正每次都是set，天然冪等性。

比如你不是上面兩個場景，那做的稍微復雜一點，你需要讓生產者發(fā)送每條數(shù)據(jù)的時候，里面加一個全局唯一的id，類似訂單id之類的東西，然后你這里消費到了之后，先根據(jù)這個id去比如redis里查一下，之前消費過嗎？如果沒有消費過，你就處理，然后這個id寫redis。如果消費過了，那你就別處理了，保證別重復處理相同的消息即可。

還有比如基于數(shù)據(jù)庫的唯一鍵來保證重復數(shù)據(jù)不會重復插入多條，我們之前線上系統(tǒng)就有這個問題，就是拿到數(shù)據(jù)的時候，每次重啟可能會有重復，因為kafka消費者還沒來得及提交offset，重復數(shù)據(jù)拿到了以后我們插入的時候，因為有唯一鍵約束了，所以重復數(shù)據(jù)只會插入報錯，不會導致數(shù)據(jù)庫中出現(xiàn)臟數(shù)據(jù)。

如何保證MQ的消費是冪等性的，需要結合具體的業(yè)務來看。

轉載于:https://www.cnblogs.com/tuhooo/p/10564558.html

總結

以上是生活随笔為你收集整理的如何保证消息不被重复消费啊（如何保证消息消费时的幂等性）？的全部內容，希望文章能夠幫你解決所遇到的問題。

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