什麼是冪等，什麼狀況下須要冪等，如何實現冪等

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

1.  
   一個訂單建立接口，第一次調用超時了，而後調用方重試了一次
2.  
   在訂單建立時，咱們須要去扣減庫存，這時接口發生了超時，調用方重試了一次
3.  
   當這筆訂單開始支付，在支付請求發出以後，在服務端發生了扣錢操做，接口響應超時了，調用方重試了一次
4.  
   一個訂單狀態更新接口，調用方連續發送了兩個消息，一個是已建立，一個是已付款。可是你先接收到已付款，而後又接收到了已建立
5.  
   在支付完成訂單以後，須要發送一條短信，當一臺機器接收到短信發送的消息以後，處理較慢。消息中間件又把消息投遞給另一臺機器處理

 

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

爲了解決以上問題，就須要保證接口的冪等性，接口的冪等性實際上就是接口可重複調用，在調用方屢次調用的狀況下，接口最終獲得的結果是一致的。有些接口能夠自然的實現冪等性，好比查詢接口，對於查詢來講，你查詢一次和兩次，對於系統來講，沒有任何影響，查出的結果也是同樣。

除了查詢功能具備自然的冪等性以外，增長、更新、刪除都要保證冪等性。那麼如何來保證冪等性呢？

全局惟一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} whereid=#{id} and version<${version}

狀態機控制

這種方法適合在有狀態機流轉的狀況下，好比就會訂單的建立和付款，訂單的付款確定是在以前，這時咱們能夠經過在設計狀態字段時，使用int類型，而且經過值類型的大小來作冪等，好比訂單的建立爲0，付款成功爲100。付款失敗爲99

在作狀態機更新時，咱們就這能夠這樣控制

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

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

 

參考連接：https://blog.csdn.net/yuhaiyang_1/article/details/81040967?utm_source=blogxgwz9