前言

冪等是分布式系統中保證數據一致性和安全性的重要保障之一，尤其是在金融、支付領域，其作為資損防控的硬性指標體現在系統架構設計中。今天我們就來淺談一下冪等相關的設計。

冪等的定義

冪等( idempotent、idempotence )的概念來源于數學，并被廣泛應用于計算機科學。在數學中，其語意是 f ( x ) = f ( f ( x ))，比如求取絕對值，abs ( x ) = abs ( abs ( x ))，就是冪等的。

在計算機科學中，冪等即相同的請求調用一次和調用多次，服務端處理的的結果相同，并且最多受理一次。

冪等的重要性

我們就拿支付公司的資金調撥舉個例子。一般的，第三方支付公司需要借助清算公司（如網聯）提供的支付通道進行備付金賬戶資金調撥，以保證資金池充足可用。當第三方支付公司發起資金調撥請求時，如果清算公司的返回結果丟失，這時，支付公司是否可以重試？如果重試，是否會發生資金的重復調撥？

互聯網公司的應用間存在物理邊界，請求和響應信息會通過網絡進行傳遞。我們說遠程調用的結果會有三個狀態：成功，失敗，未知。前兩者都是明確的狀態，而未知具有不確定性，一般都是由網絡超時、丟包引起的。如上例中，如果出現了超時，其實有兩種方案，我們可以建立查詢補償機制，來研判是否要重新發起資金調撥。或者，清算公司做好冪等控制，支付公司可以無腦重試，既可以保證資金調撥業務的正常，又能保證不會發生多次調撥。

在架構設計中，冪等的應用面非常廣泛，比如 MQ 規避重復消費、表單規避重復提交等。

冪等設計

冪等兩大要素

冪等包含兩大要素，冪等標記和關鍵請求參數。

冪等號：它對應服務端的唯一約束，在設計上，它一般由上游的冪等單號和來源組成。服務端的接口文檔中，需要明確指出冪等號的信息組成，它的作用是對請求信息進行身份標識，相同冪等號的請求將被服務端識別為同一請求。

關鍵請求信息：接收的核心業務信息，常見的如收款賬戶、打款賬戶，打款金額、幣種、商品數量等等。相同的請求中，調用方需要保證關鍵請求信息不變，一旦信息發生變動，則需要替換冪等號。

冪等原則

調用方必須保證冪等號的唯一性、不變性

說明

調用方需要保證冪等號不重復，且對同一業務單據的同一次操作，無論請求多少次，都要保證冪等號不變。

反例

冪等號重復，原因基本如下

• sequence cycle 問題，未評估好業務量同 sequence 增長速度，導致冪等號重復。
• sequence 步長、分段設置問題，導致跨區域/單元/庫/表冪等號重復;

冪等號變化，原因基本如下

• 事務中生成冪等號，并發起遠程調用，調用超時本地事務回滾，第二次請求又會生成新的冪等號。

調用方必須保證關鍵業務請求參數的不變性

說明

當服務端沒有返回結果時，調用方關鍵業務請求參數不允許變更。

反例

初次請求，由于網絡異常導致 timeout 調用方沒有拿到結果，而服務端受理成功。客戶端修改單據金額，請求信息發生變化，調用方與服務端處理出錯。

img

調用方禁止冪等號純內存拼接，不進行持久化

說明

冪等號不持久化，對于異步回執處理，上下游數據稽核帶來困難，所以冪等號持久化是一個基本要求。

反例

RPC 調用，調用方的冪等號，是內存中根據業務映射拼接得來，不做持久化。

//內存中拼接冪等號
request.setRequestId(BizTypeEnum.getPrefix(×xxDO.getBizType()) + xxxDO.getId()):

調用方冪等號生成事務內禁止包含 RPC

反例

transactionTemplate.execute (status ->
    //生成流水號 xxx 
    SerialDO serialDO = buildSerialDO();
    //播入 aaa 表
    serialDAO.insert(serialDO);
    someDAO.update (someDO) ;
    // dubbo 調用 rpc，流水號 xxxId 作為冪等號
    invokeRpc(request);
    return true,
));

正例

• RPC 放在事務外面

transactionTemplate.execute (status ->
    //生成流水號 xxx 
    SerialDO serialDO =  buildSerialDO();
    //播入 aaa 表
    serialDAO.insert(serialDO);
    someDAO.update (someDO) ;
    return true;
));
// dubbo 調用 rpc，流水號 xxxId 作為冪等號
invokeRpc(request);

• 使用事務同步器：如果事務在外層開啟，為了不破壞代碼結構，使用事務同步器，事務提交后發起 RPC 調用，調用異常后應用需要做恢復。

/**
* 外層已開啟事務
*/
public static void execute (){
  //更新單據狀態
  Runnable runnable = () -> {
    response = dubboService.call(request);
  };
 register(runnable);
}
 

public static void register (Runnable runnable) {
  if (TransactionSynchronizationManager.isActualTrangactionActive()) {
    TransactionSynchronizationManager.registersynchronization(
      new TransactionSynchronizationAdapter() {
        @Override
        public void afterCommit () {
          runnable.run(); 
        } 
      }
    ); 
  } else {
    LOGGER.debug( "No active transaction.");
    runnable.run();
  }
}

• 業務自研組件：事務中插入本地任務，統一恢復執行。

服務端不能單純依賴查詢做冪等

說明

分布式下并發場景，并不能單純的依賴查詢做到插入 冪等。常見唯一性保障方式:

• DB 約束：對插入流水的冪等號建 DB 唯一索引約束
• 分布式鎖：如 redis、 zookeeper 等。若持久層在 DB，不推存使用（依賴外部存儲做冪等控制，與 DB 的強一致性無法保證），涉及資金等強一致性場景不推薦。

反例

RPC 調用超時，本地事務回滾。下次重試，會生成新的冪等號，導致資損。

服務端必須保證受理結果一致性

說明

針對相同請求，不論調用方請求多少次，服務端僅受理一次，且受理結果相同。

反例

售中退款的場景中，第一次服務端正常受理調用方請求，但調用方因為超時丟棄響應；當第二次調用方重試，服務端發現退款金額不足，返回受理失敗，導致故障。

//1、基本校驗
//2、悲觀鎖內，可退款金額判斷；
Assert.isTrue(refundable(xxx), "cannot refund");

//3、邏輯處理
try {
 process(xxx);
} catch (Exception e) {
   //冪等判斷處理
}

調用方收到服務端冪等結果后，比對關鍵業務參數

說明

客戶端收到服務端結果后，本著不信任的原則，針對關鍵業務請求參數如賬戶、 金額同服務端受理內容對比。

反例

服務端做冪等判斷時，只看冪等號，雖然第二次請求冪等號不變，但是金額又可能被篡改，如果服務端直接返回成功，將導致資金損失。

正例

• 服務端：根據冪等號查詢 DB 流水，返回已經受理的關鍵業務信息。
• 調用方：對服務方返回的冪等內容做校驗，確保與預期一致。

總結

以上規則是借鑒歷史項目和互聯網經驗總結而成，主要側重于冪等設計的原則，冪等的落地方案有很多，比如冪等表、樂觀鎖、悲觀鎖等，這里就不贅述。