淺談冪等,大家都看明白了嗎?
前言
冪等是分布式系統(tǒng)中保證數(shù)據(jù)一致性和安全性的重要保障之一,尤其是在金融、支付領(lǐng)域,其作為資損防控的硬性指標體現(xiàn)在系統(tǒng)架構(gòu)設(shè)計中。今天我們就來淺談一下冪等相關(guān)的設(shè)計。
冪等的定義
冪等( 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)絡(luò)進行傳遞。我們說遠程調(diào)用的結(jié)果會有三個狀態(tài):成功,失敗,未知。前兩者都是明確的狀態(tài),而未知具有不確定性,一般都是由網(wǎng)絡(luò)超時、丟包引起的。如上例中,如果出現(xiàn)了超時,其實有兩種方案,我們可以建立查詢補償機制,來研判是否要重新發(fā)起資金調(diào)撥?;蛘?,清算公司做好冪等控制,支付公司可以無腦重試,既可以保證資金調(diào)撥業(yè)務的正常,又能保證不會發(fā)生多次調(diào)撥。
在架構(gòu)設(shè)計中,冪等的應用面非常廣泛,比如 MQ 規(guī)避重復消費、表單規(guī)避重復提交等。
冪等設(shè)計
冪等兩大要素
冪等包含兩大要素,冪等標記和關(guān)鍵請求參數(shù)。
冪等號:它對應服務端的唯一約束,在設(shè)計上,它一般由上游的冪等單號和來源組成。服務端的接口文檔中,需要明確指出冪等號的信息組成,它的作用是對請求信息進行身份標識,相同冪等號的請求將被服務端識別為同一請求。
關(guān)鍵請求信息:接收的核心業(yè)務信息,常見的如收款賬戶、打款賬戶,打款金額、幣種、商品數(shù)量等等。相同的請求中,調(diào)用方需要保證關(guān)鍵請求信息不變,一旦信息發(fā)生變動,則需要替換冪等號。
冪等原則
調(diào)用方必須保證冪等號的唯一性、不變性
說明
調(diào)用方需要保證冪等號不重復,且對同一業(yè)務單據(jù)的同一次操作,無論請求多少次,都要保證冪等號不變。
反例
冪等號重復,原因基本如下
- sequence cycle 問題,未評估好業(yè)務量同 sequence 增長速度,導致冪等號重復。
- sequence 步長、分段設(shè)置問題,導致跨區(qū)域/單元/庫/表冪等號重復;
冪等號變化,原因基本如下
- 事務中生成冪等號,并發(fā)起遠程調(diào)用,調(diào)用超時本地事務回滾,第二次請求又會生成新的冪等號。
調(diào)用方必須保證關(guān)鍵業(yè)務請求參數(shù)的不變性
說明
當服務端沒有返回結(jié)果時,調(diào)用方關(guān)鍵業(yè)務請求參數(shù)不允許變更。
反例
初次請求,由于網(wǎng)絡(luò)異常導致 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é)果后,比對關(guān)鍵業(yè)務參數(shù)
說明
客戶端收到服務端結(jié)果后,本著不信任的原則,針對關(guān)鍵業(yè)務請求參數(shù)如賬戶、 金額同服務端受理內(nèi)容對比。
反例
服務端做冪等判斷時,只看冪等號,雖然第二次請求冪等號不變,但是金額又可能被篡改,如果服務端直接返回成功,將導致資金損失。
正例
- 服務端:根據(jù)冪等號查詢 DB 流水,返回已經(jīng)受理的關(guān)鍵業(yè)務信息。
- 調(diào)用方:對服務方返回的冪等內(nèi)容做校驗,確保與預期一致。
總結(jié)
以上規(guī)則是借鑒歷史項目和互聯(lián)網(wǎng)經(jīng)驗總結(jié)而成,主要側(cè)重于冪等設(shè)計的原則,冪等的落地方案有很多,比如冪等表、樂觀鎖、悲觀鎖等,這里就不贅述。