這篇文章將為大家詳細講解有關MQ中消息重復消費及解決是怎樣的，文章內(nèi)容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

10年積累的網(wǎng)站設計制作、成都網(wǎng)站制作經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站設計制作后付款的網(wǎng)站建設流程，更有怒江州免費網(wǎng)站建設讓你可以放心的選擇與我們合作。

重復消費原因

因為在網(wǎng)絡延遲的情況下，消息重復發(fā)送的問題不可避免的發(fā)生，如果非要實現(xiàn)消息不可重復發(fā)送，那基本太難，因為網(wǎng)絡環(huán)境無法預知，還會使程序復雜度加大，因此默認允許消息重復發(fā)送。
只要通過網(wǎng)絡交換數(shù)據(jù)，就無法避免這個問題。所以解決這個問題的辦法就是繞過這個問題。那么問題就變成了：如果消費端收到兩條一樣的消息，應該怎樣處理？

重復消費問題例子

RabbitMQ、RocketMQ、Kafka，都有可能會出現(xiàn)消息重復消費的問題，正常。因為這問題通常不是 MQ 自己保證的，是由我們開發(fā)來保證的。

RabbitMQ

RabbitMQ 不保證消息不重復，如果你的業(yè)務需要保證嚴格的不重復消息，需要你自己在業(yè)務端去重。

AMQP 消費者確認機制
AMQP 定義了消費者確認機制（message ack），如果一個消費者應用崩潰掉（此時連接會斷掉，broker 會得知），但是 broker 尚未獲得 ack，那么消息會被重新放入隊列。所以 AMQP 提供的是“至少一次交付”（at-least-once delivery），異常情況下，消息會被重復消費，此時業(yè)務要實現(xiàn)冪等性（重復消息處理）。

1. 消息重復發(fā)布：不存在，因為 AMQP 定義了事務（tx transaction）來確保生產(chǎn)消息被 broker 接收并成功入隊。TX 事務是阻塞調用，生產(chǎn)者需等待 broker 寫磁盤后返回的確認，之后才能繼續(xù)發(fā)送消息。事務提交失敗時（如 broker 宕機場景），broker 并不保證提交的消息全部入隊。RabbitMQ 使用 confirm 機制來優(yōu)化生產(chǎn)消息的確認（可以持續(xù)發(fā)布消息，但會批量回復確認）。

2. 消息重復消費：AMQP 提供的是“至少一次交付”（at-least-once delivery），異常情況下，消息會被重復消費，此時業(yè)務要實現(xiàn)冪等性（重復消息處理）。
   Kafka
   Kafka 實際上有個 offset 的概念，就是每個消息寫進去，都有一個 offset，代表消息的序號，然后 consumer 消費了數(shù)據(jù)之后，每隔一段時間（定時定期），會把自己消費過的消息的 offset 提交一下。

假如，有這么個場景。數(shù)據(jù) 1/2/3 依次進入 kafka，kafka 會給這三條數(shù)據(jù)每條分配一個 offset，代表這條數(shù)據(jù)的序號，分配的 offset 依次是 152，153，154。消費者從 kafka 去消費的時候，也是按照這個順序去消費。假如當消費者消費了 offset=153 的這條數(shù)據(jù)，剛準備去提交 offset 到 zookeeper，此時消費者進程被重啟了。那么此時消費過的數(shù)據(jù) 1，2 的 offset 并沒有提交，kafka 也就不知道你已經(jīng)消費了 offset=153 這條數(shù)據(jù)。那么重啟之后，消費者會找 kafka 把上次消費到的那個地方后面的數(shù)據(jù)繼續(xù)傳遞過來。數(shù)據(jù) 1，2 再次被消費。

如果消費者干的事兒是拿一條數(shù)據(jù)就往數(shù)據(jù)庫里寫一條，會導致說，你可能就把數(shù)據(jù) 1，2 在數(shù)據(jù)庫里插入了 2 次，那么數(shù)據(jù)就錯啦。其實重復消費不可怕，可怕的是你沒考慮到重復消費之后，怎么保證冪等性。

解決方案
消費端處理消息的業(yè)務邏輯保持冪等性。
冪等性，通俗點說，就一個數(shù)據(jù)，或者一個請求，給你重復來多次，你得確保對應的數(shù)據(jù)是不會改變的，不能出錯。

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

2. 再比如，你拿到這個消息做redis的set的操作，那就容易了，不用解決，因為你無論set幾次結果都是一樣的，set操作本來就算冪等操作。

3. 如果上面兩種情況還不行，上大招。準備一個第三方介質,來做消費記錄。以redis為例，給消息分配一個全局id，只要消費過該消息，將<id,message>以K-V形式寫入redis。那消費者開始消費前，先去redis中查詢有沒消費記錄即可。

關于MQ中消息重復消費及解決是怎樣的就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

分享文章：MQ中消息重復消費及解決是怎樣的
網(wǎng)站路徑：http://chinadenli.net/article6/gehhog.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供App設計、域名注冊、品牌網(wǎng)站制作、微信公眾號、外貿(mào)建站、響應式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)