這個是網際網路公司使用 MQ 基本要捷俊的問題，本質上還是問你使用訊息佇列如何保證冪等性，以kafka來舉例，Kafka 有個 offset 的概念，每個訊息寫進去，都有一個 offset，代表訊息的序號，消費者消費之後，每隔一段時間會定時定期的 會把一消費過的訊息的 offset 提交一下，表示已經消費過，下次我重重啟或者服務死掉在重啟的時候，會繼續從上次消費到的 offset 來繼續消費。但是還是得結合業務來思考，比如你拿個資料要寫庫，你先根據主鍵查一下，如果這資料都有了，你就別插入了，update 一下好吧，最終還是要在資料方面在做一次去重操作

一、前言

我們小夥伴應該都聽說夠訊息中介軟體MQ，如：RabbitMQ，RocketMQ，Kafka等。引入中介軟體的好處可以起到抗高併發，削峰，業務解耦的作用。

如上圖：

（1）訂單服務投遞訊息給MQ中介軟體

（2）物流服務監聽MQ中介軟體訊息，從而進行消費

二、分析問題

小夥伴們對此會有些疑問，訂單服務發起訊息服務，返回成功不就成功了嗎？如下面的虛擬碼：

上面程式碼中，一般傳送訊息就是這麼寫的，小夥伴們覺得有什麼問題嗎？

下邊說一個場景，如果MQ伺服器突然宕機了會出現什麼情況？是不是我們訂單服務發過去的訊息全部沒有了嗎？是的，一般MQ中介軟體為了提高系統的吞吐量會把訊息儲存在記憶體中，如果不作其他處理，MQ伺服器一旦宕機，訊息將全部丟失。這個是業務不允許的，造成很大的影響。

三、持久化

有經驗的小夥伴會說，我知道一個方法就是把訊息持久化，RabbitMQ中發訊息的時候會有個durable引數可以設定，設定為true，就會持久化。

這樣的話MQ伺服器即使宕機，重啟後磁碟檔案中有訊息的儲存，這樣就不會丟失了吧。是的這樣就一定機率的保障了訊息不丟失。

但還會有個場景，就是訊息剛剛儲存到MQ記憶體中，但還沒有來得及更新到磁碟檔案中，突然宕機了。（我靠，這個時間這麼短，也會出現，機率太低了吧），這個場景在持續的大量訊息投遞的過程中，會很常見。

那怎麼辦？我們如何作才能保障一定會持久化到磁碟上面呢？

四、confirm機制

上面問題出現在，沒有人告訴我們持久化是否成功。好在很多MQ有回撥通知的特性，RabbitMQ就有confirm機制來通知我們是否持久化成功？

confirm機制的原理：

（1）訊息生產者把訊息傳送給MQ，如果接收成功，MQ會返回一個ack訊息給生產者；

（2）如果訊息接收不成功，MQ會返回一個nack訊息給生產者；

上面的虛擬碼，有兩個處理訊息方式，就是ack回撥和nack回撥。

這樣是不是就可以保障100%訊息不丟失了呢？

我們看一下confirm的機制，試想一下，如果我們生產者每發一條訊息，都要MQ持久化到磁碟中，然後再發起ack或nack的回撥。這樣的話是不是我們MQ的吞吐量很不高，因為每次都要把訊息持久化到磁碟中。寫入磁碟這個動作是很慢的。這個在高併發場景下是不能夠接受的，吞吐量太低了。

所以MQ持久化磁碟真實的實現，是透過非同步呼叫處理的，他是有一定的機制，如：等到有幾千條訊息的時候，會一次性的刷盤到磁碟上面。而不是每來一條訊息，就刷盤一次。

所以comfirm機制其實是一個非同步監聽的機制，是為了保證系統的高吞吐量，這樣就導致了還是不能夠100%保障訊息不丟失，因為即使加上了confirm機制，訊息在MQ記憶體中還沒有刷盤到磁碟就宕機了，還是沒法處理。

說了這麼多，還是沒法確保，那怎麼辦呢？？？

五、訊息提前持久化 + 定時任務

其實本質的原因是無法確定是否持久化？那我們是不是可以自己讓訊息持久化呢？答案是可以的，我們的方案再一步的演化。

上圖流程：

（1）訂單服務生產者再投遞訊息之前，先把訊息持久化到Redis或DB中，建議Redis，高效能。訊息的狀態為傳送中。

（4）這邊加了個定時任務，來拉取隔一定時間了，訊息狀態還是為傳送中的，這個狀態就表明，訂單服務是沒有收到ack成功訊息。

這樣的機制其實就是一個補償機制，我不管MQ有沒有真正的接收到，只要我的Redis中的訊息狀態也是為【傳送中】，就表示此訊息沒有正確成功投遞。再啟動定時任務去監控，發起補償投遞。

當然定時任務那邊我們還可以加上一個補償的次數，如果大於3次，還是沒有收到ack訊息，那就直接把訊息的狀態設定為【失敗】，由人工去排查到底是為什麼？

這樣的話方案就比較完美了，保障了100%的訊息不丟失（當然不包含磁碟也壞了，可以做主從方案）。

不過這樣的方案，就會有可能傳送多次相同的訊息，很有可能MQ已經收到了訊息，就是ack訊息回撥時出現網路故障，沒有讓生產者收到。

那就要要求消費者一定在消費的時候保障冪等性！

六、冪等含義

我們先了解一下什麼叫冪等？在分散式應用中，冪等是非常重要的，也就是相同條件下對一個業務的操作，不管操作多少次，結果都是一樣。

6.1、為什麼要有冪等這種場景？

為什麼要有冪等這種場景？因為在大的系統中，都是分散式部署，如：訂單業務 和 庫存業務有可能都是獨立部署的，都是單獨的服務。使用者下訂單，會呼叫到訂單服務和庫存服務。

因為分散式部署，很有可能在呼叫庫存服務時，因為網路等原因，訂單服務呼叫失敗，但其實庫存服務已經處理完成，只是返回給訂單服務處理結果時出現了異常。這個時候一般系統會作補償方案，也就是訂單服務再此放起庫存服務的呼叫，庫存減1。

這樣就出現了問題，其實上一次呼叫已經減了1，只是訂單服務沒有收到處理結果。現在又呼叫一次，又要減1，這樣就不符合業務了，多扣了。

冪等這個概念就是，不管庫存服務在相同條件下呼叫幾次，處理結果都一樣。這樣才能保證補償方案的可行性。

6.2、樂觀鎖方案

借鑑資料庫的樂觀鎖機制，如：

根據version版本，也就是在操作庫存前先獲取當前商品的version版本號，然後操作的時候帶上此version號。我們梳理下，我們第一次操作庫存時，得到version為1，呼叫庫存服務version變成了2；但返回給訂單服務出現了問題，訂單服務又一次發起呼叫庫存服務，當訂單服務傳如的version還是1，再執行上面的sql語句時，就不會執行；因為version已經變為2了，where條件就不成立。這樣就保證了不管呼叫幾次，只會真正的處理一次。

6.3、唯一ID + 指紋碼

原理就是利用資料庫主鍵去重，業務完成後插入主鍵標識

唯一ID就是業務表的唯一的主鍵，如商品ID指紋碼就是為了區別每次正常操作的碼，每次操作時生成指紋碼；可以用時間戳+業務編號的方式。 上面的sql語句：返回如果為0 表示沒有操作過，那業務操作後就可以insert into t_check(唯一ID+指紋碼)返回如果大於0 表示操作過，就直接返回

好處：實現簡單

壞處：高併發下資料庫瓶頸

解決方案：根據ID進行分庫分表進行演算法路由

6.4、Redis原子操作

利用redis的原子操作，做個操作完成的標記。這個效能就比較好。