在微服務架構下，我們在完成一個訂單流程時經常遇到下面的場景：
- 一個訂單創建接口，第一次調用超時了，然后調用方重試了一次
- 在訂單創建時，我們需要去扣減庫存，這時接口發生了超時，調用方重試了一次
- 當這筆訂單開始支付，在支付請求發出之后，在服務端發生了扣錢操作，接口響應超時了，調用方重試了一次
- 一個訂單狀態更新接口，調用方連續發送了兩個消息，一個是已創建，一個是已付款。但是你先接收到已付款，然后又接收到了已創建
- 在支付完成訂單之后，需要發送一條短信，當一台機器接收到短信發送的消息之后，處理較慢。消息中間件又把消息投遞給另外一台機器處理
以上問題，就是在單體架構轉成微服務架構之后，帶來的問題。當然不是說單體架構下沒有這些問題，在單體架構下同樣要避免重復請求。但是出現的問題要比這少得多。
為了解決以上問題，就需要保證接口的冪等性，接口的冪等性實際上就是接口可重復調用，在調用方多次調用的情況下，接口最終得到的結果是一致的。有些接口可以天然的實現冪等性，比如查詢接口，對於查詢來說，你查詢一次和兩次，對於系統來說，沒有任何影響，查出的結果也是一樣。
除了查詢功能具有天然的冪等性之外，增加、更新、刪除都要保證冪等性。那么如何來保證冪等性呢？
全局唯一ID
如果使用全局唯一ID，就是根據業務的操作和內容生成一個全局ID，在執行操作前先根據這個全局唯一ID是否存在，來判斷這個操作是否已經執行。如果不存在則把全局ID，存儲到存儲系統中，比如數據庫、redis等。如果存在則表示該方法已經執行。
從工程的角度來說，使用全局ID做冪等可以作為一個業務的基礎的微服務存在，在很多的微服務中都會用到這樣的服務，在每個微服務中都完成這樣的功能，會存在工作量重復。另外打造一個高可靠的冪等服務還需要考慮很多問題，比如一台機器雖然把全局ID先寫入了存儲，但是在寫入之后掛了，這就需要引入全局ID的超時機制。
使用全局唯一ID是一個通用方案，可以支持插入、更新、刪除業務操作。但是這個方案看起來很美但是實現起來比較麻煩，下面的方案適用於特定的場景，但是實現起來比較簡單。
去重表
這種方法適用於在業務中有唯一標的插入場景中，比如在以上的支付場景中，如果一個訂單只會支付一次，所以訂單ID可以作為唯一標識。這時，我們就可以建一張去重表，並且把唯一標識作為唯一索引，在我們實現時，把創建支付單據和寫入去去重表，放在一個事務中，如果重復創建，數據庫會拋出唯一約束異常，操作就會回滾。
插入或更新
這種方法插入並且有唯一索引的情況，比如我們要關聯商品品類，其中商品的ID和品類的ID可以構成唯一索引，並且在數據表中也增加了唯一索引。這時就可以使用InsertOrUpdate操作。在mysql數據庫中如下：
|
1
2
3
4
|
insert into goods_category (goods_id,category_id,create_time,update_time)
values(#{goodsId},#{categoryId},now(),now())
on DUPLICATE KEY UPDATE
update_time=
now()
|
多版本控制
這種方法適合在更新的場景中，比如我們要更新商品的名字，這時我們就可以在更新的接口中增加一個版本號，來做冪等
|
1
|
boolean updateGoodsName(int id,String newName,int version);
|
在實現時可以如下
|
1
|
update goods set name=#{newName},version=#{version} where id=#{id} andversion<${version}
|
1. 通過版本號實現
update table_xxx set name=#name#,version=version+1 where version=#version#
如下圖(來自網上)： 
2. 通過條件限制
update table_xxx set avai_amount=avai_amount-#subAmount# where avai_amount-#subAmount# >= 0
要求：quality-#subQuality# >= ，這個情景適合不用版本號，只更新是做數據安全校驗，適合庫存模型，扣份額和回滾份額，性能更高
注意：樂觀鎖的更新操作，最好用主鍵或者唯一索引來更新,這樣是行鎖，否則更新時會鎖表，上面兩個sql改成下面的兩個更好
update table_xxx set name=#name#,version=version+1 where id=#id# and version=#version#
update table_xxx set avai_amount=avai_amount-#subAmount# where id=#id# and avai_amount-#subAmount# >= 0
狀態機控制
這種方法適合在有狀態機流轉的情況下，比如就會訂單的創建和付款，訂單的付款肯定是在之前，這時我們可以通過在設計狀態字段時，使用int類型，並且通過值類型的大小來做冪等，比如訂單的創建為0，付款成功為100。付款失敗為99
在做狀態機更新時，我們就這可以這樣控制
|
1
|
update `order` set status=#{status} where id=#{id} and status<#{status}
|
以上就是保證接口冪等性的一些方法。
10. 對外提供接口的api如何保證冪等
如銀聯提供的付款接口：需要接入商戶提交付款請求時附帶：source來源，seq序列號
source+seq在數據庫里面做唯一索引，防止多次付款，(並發時，只能處理一個請求)
重點：
對外提供接口為了支持冪等調用，接口有兩個字段必須傳，一個是來源source，一個是來源方序列號seq，這個兩個字段在提供方系統里面做聯合唯一索引，這樣當第三方調用時，先在本方系統里面查詢一下，是否已經處理過，返回相應處理結果；沒有處理過，進行相應處理，返回結果。注意，為了冪等友好，一定要先查詢一下，是否處理過該筆業務，不查詢直接插入業務系統，會報錯，但實際已經處理了。
總結：
冪等性應該是合格程序員的一個基因，在設計系統時，是首要考慮的問題，尤其是在像支付寶，銀行，互聯網金融公司等涉及的都是錢的系統，既要高效，數據也要准確，所以不能出現多扣款，多打款等問題，這樣會很難處理，用戶體驗也不好