什麼是幂等，什麼情況下需要幂等，如何實作幂等

在微服務架構下，我們在完成一個訂單流程時經常遇到下面的場景：

一個訂單建立接口，第一次調用逾時了，然後調用方重試了一次

在訂單建立時，我們需要去扣減庫存，這時接口發生了逾時，調用方重試了一次

當這筆訂單開始支付，在支付請求發出之後，在服務端發生了扣錢操作，接口響應逾時了，調用方重試了一次

一個訂單狀态更新接口，調用方連續發送了兩個消息，一個是已建立，一個是已付款。但是你先接收到已付款，然後又接收到了已建立

在支付完成訂單之後，需要發送一條短信，當一台機器接收到短信發送的消息之後，處理較慢。消息中間件又把消息投遞給另外一台機器處理

以上問題，就是在單體架構轉成微服務架構之後，帶來的問題。當然不是說單體架構下沒有這些問題，在單體架構下同樣要避免重複請求。但是出現的問題要比這少得多。

為了解決以上問題，就需要保證接口的幂等性，接口的幂等性實際上就是接口可重複調用，在調用方多次調用的情況下，接口最終得到的結果是一緻的。有些接口可以天然的實作幂等性，比如查詢接口，對于查詢來說，你查詢一次和兩次，對于系統來說，沒有任何影響，查出的結果也是一樣。

除了查詢功能具有天然的幂等性之外，增加、更新、删除都要保證幂等性。那麼如何來保證幂等性呢？

如果使用全局唯一ID，就是根據業務的操作和内容生成一個全局ID，在執行操作前先根據這個全局唯一ID是否存在，來判斷這個操作是否已經執行。如果不存在則把全局ID，存儲到存儲系統中，比如資料庫、redis等。如果存在則表示該方法已經執行。

從工程的角度來說，使用全局ID做幂等可以作為一個業務的基礎的微服務存在，在很多的微服務中都會用到這樣的服務，在每個微服務中都完成這樣的功能，會存在工作量重複。另外打造一個高可靠的幂等服務還需要考慮很多問題，比如一台機器雖然把全局ID先寫入了存儲，但是在寫入之後挂了，這就需要引入全局ID的逾時機制。

使用全局唯一ID是一個通用方案，可以支援插入、更新、删除業務操作。但是這個方案看起來很美但是實作起來比較麻煩，下面的方案适用于特定的場景，但是實作起來比較簡單。

這種方法适用于在業務中有唯一标的插入場景中，比如在以上的支付場景中，如果一個訂單隻會支付一次，是以訂單ID可以作為唯一辨別。這時，我們就可以建一張去重表，并且把唯一辨別作為唯一索引，在我們實作時，把建立支付單據和寫入去去重表，放在一個事務中，如果重複建立，資料庫會抛出唯一限制異常，操作就會復原。

這種方法插入并且有唯一索引的情況，比如我們要關聯商品品類，其中商品的ID和品類的ID可以構成唯一索引，并且在資料表中也增加了唯一索引。這時就可以使用InsertOrUpdate操作。在mysql資料庫中如下：

insert into goods_category (goods_id,category_id,create_time,update_time)

values(#{goodsId},#{categoryId},now(),now())

on DUPLICATE KEY UPDATE

update_time=now()

這種方法适合在更新的場景中，比如我們要更新商品的名字，這時我們就可以在更新的接口中增加一個版本号，來做幂等

boolean updateGoodsName(int id,String newName,int version);

在實作時可以如下

update goods set name=#{newName},version=#{version} whereid=#{id} and version<${version}

這種方法适合在有狀态機流轉的情況下，比如就會訂單的建立和付款，訂單的付款肯定是在之前，這時我們可以通過在設計狀态字段時，使用int類型，并且通過值類型的大小來做幂等，比如訂單的建立為0，付款成功為100。付款失敗為99

在做狀态機更新時，我們就這可以這樣控制

update `order` set status=#{status} where id=#{id} and status<#{status}

以上就是保證接口幂等性的一些方法。

繼續閱讀