前言

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

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供德清網(wǎng)站建設、德清做網(wǎng)站、德清網(wǎng)站設計、德清網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、德清企業(yè)網(wǎng)站模板建站服務，十年德清做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。

冪等的定義

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

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

冪等的重要性

我們就拿支付公司的資金調(diào)撥舉個例子。一般的，第三方支付公司需要借助清算公司（如網(wǎng)聯(lián)）提供的支付通道進行備付金賬戶資金調(diào)撥，以保證資金池充足可用。當?shù)谌街Ц豆景l(fā)起資金調(diào)撥請求時，如果清算公司的返回結(jié)果丟失，這時，支付公司是否可以重試？如果重試，是否會發(fā)生資金的重復調(diào)撥？

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

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

冪等設計

冪等兩大要素

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

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

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

冪等原則

調(diào)用方必須保證冪等號的唯一性、不變性

說明

調(diào)用方需要保證冪等號不重復，且對同一業(yè)務單據(jù)的同一次操作，無論請求多少次，都要保證冪等號不變。

反例

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

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

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

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

調(diào)用方必須保證關鍵業(yè)務請求參數(shù)的不變性

說明

當服務端沒有返回結(jié)果時，調(diào)用方關鍵業(yè)務請求參數(shù)不允許變更。

反例

初次請求，由于網(wǎng)絡異常導致 timeout 調(diào)用方?jīng)]有拿到結(jié)果，而服務端受理成功?？蛻舳诵薷膯螕?jù)金額，請求信息發(fā)生變化，調(diào)用方與服務端處理出錯。

img

調(diào)用方禁止冪等號純內(nèi)存拼接，不進行持久化

說明

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

反例

RPC 調(diào)用，調(diào)用方的冪等號，是內(nèi)存中根據(jù)業(yè)務映射拼接得來，不做持久化。

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

調(diào)用方冪等號生成事務內(nèi)禁止包含 RPC

反例

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

正例

• RPC 放在事務外面

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

• 使用事務同步器：如果事務在外層開啟，為了不破壞代碼結(jié)構(gòu)，使用事務同步器，事務提交后發(fā)起 RPC 調(diào)用，調(diào)用異常后應用需要做恢復。

/**
* 外層已開啟事務
*/
public static void execute (){
  //更新單據(jù)狀態(tài)
  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();
  }
}

• 業(yè)務自研組件：事務中插入本地任務，統(tǒng)一恢復執(zhí)行。

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

說明

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

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

反例

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

服務端必須保證受理結(jié)果一致性

說明

針對相同請求，不論調(diào)用方請求多少次，服務端僅受理一次，且受理結(jié)果相同。

反例

售中退款的場景中，第一次服務端正常受理調(diào)用方請求，但調(diào)用方因為超時丟棄響應；當?shù)诙握{(diào)用方重試，服務端發(fā)現(xiàn)退款金額不足，返回受理失敗，導致故障。

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

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

調(diào)用方收到服務端冪等結(jié)果后，比對關鍵業(yè)務參數(shù)

說明

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

反例

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

正例

• 服務端：根據(jù)冪等號查詢 DB 流水，返回已經(jīng)受理的關鍵業(yè)務信息。
• 調(diào)用方：對服務方返回的冪等內(nèi)容做校驗，確保與預期一致。

總結(jié)

以上規(guī)則是借鑒歷史項目和互聯(lián)網(wǎng)經(jīng)驗總結(jié)而成，主要側(cè)重于冪等設計的原則，冪等的落地方案有很多，比如冪等表、樂觀鎖、悲觀鎖等，這里就不贅述。

當前標題：淺談冪等，大家都看明白了嗎？
分享網(wǎng)址：http://uogjgqi.cn/article/cdiespj.html