冪等性介面方案

什麼是介面的冪等性

介面可重複呼叫，在呼叫方多次呼叫的情況下，介面最終得到的結果是一致的。有些介面可以天然的實現冪等性，比如查詢介面，對於查詢來說，你查詢一次和兩次，對於系統來說，沒有任何影響，查出的結果也是一樣。

問題舉例:
在微服務架構下，我們在完成一個訂單流程時經常遇到下面的場景：
1. (重複建立)一個訂單建立介面，第一次呼叫超時了，然後呼叫方重試了一次
2. (重複更新)在訂單建立時，我們需要去扣減庫存，這時介面發生了超時，呼叫方重試了一次
3. (重複更新)當這筆訂單開始支付，在支付請求發出之後，在服務端發生了扣錢操作，介面響應超時了，呼叫方重試了一次
4. (無序更新)一個訂單狀態更新介面，呼叫方連續傳送了兩個訊息，一個是已建立，一個是已付款。但是你先接收到已付款，然後又接收到了已建立

解決方案

• 全域性唯一ID(通用解決方案)

  • 如果使用全域性唯一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} where id=#{id} and version<${version}
    

• 狀態機控制(適用於某狀態欄位有序更新)

  • 這種方法適合在有狀態機流轉的情況下，比如就會訂單的建立和付款，訂單的建立肯定是在之前，這時我們可以通過在設計狀態欄位時，使用int型別，並且通過值型別的大小來做冪等，比如訂單的建立為0，付款成功為100。付款失敗為99在做狀態機更新時，我們就這可以這樣控制

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