我們知道,應(yīng)用系統(tǒng)在分布式的情況下,在通信時(shí)會(huì)有著一個(gè)顯著的問題,即一個(gè)業(yè)務(wù)流程往往需要組合一組服務(wù),且單單一次通信可能會(huì)經(jīng)過 DNS 服務(wù),網(wǎng)卡、交換機(jī)、路由器、負(fù)載均衡等設(shè)備,而這些服務(wù)于設(shè)備都不一定是一直穩(wěn)定的,在數(shù)據(jù)傳輸?shù)恼麄€(gè)過程中,只要任意一個(gè)環(huán)節(jié)出錯(cuò),都會(huì)導(dǎo)致問題的產(chǎn)生。
這樣的事情在微服務(wù)下就更為明顯了,因?yàn)闃I(yè)務(wù)需要在一致性上的保證。也就是說,如果一個(gè)步驟失敗了,要么不斷重試保證所有的步驟都成功,要么回滾到以前的服務(wù)調(diào)用。
因此我們可以對(duì)業(yè)務(wù)補(bǔ)償?shù)倪^程進(jìn)行一個(gè)定義,即當(dāng)某個(gè)操作發(fā)生了異常時(shí),如何通過內(nèi)部機(jī)制將這個(gè)異常產(chǎn)生的「不一致」?fàn)顟B(tài)消除掉。
一、關(guān)于業(yè)務(wù)補(bǔ)償機(jī)制
1、什么是業(yè)務(wù)補(bǔ)償
我們知道,應(yīng)用系統(tǒng)在分布式的情況下,在通信時(shí)會(huì)有著一個(gè)顯著的問題,即一個(gè)業(yè)務(wù)流程往往需要組合一組服務(wù),且單單一次通信可能會(huì)經(jīng)過 DNS 服務(wù),網(wǎng)卡、交換機(jī)、路由器、負(fù)載均衡等設(shè)備,而這些服務(wù)于設(shè)備都不一定是一直穩(wěn)定的,在數(shù)據(jù)傳輸?shù)恼麄€(gè)過程中,只要任意一個(gè)環(huán)節(jié)出錯(cuò),都會(huì)導(dǎo)致問題的產(chǎn)生。
這樣的事情在微服務(wù)下就更為明顯了,因?yàn)闃I(yè)務(wù)需要在一致性上的保證。也就是說,如果一個(gè)步驟失敗了,要么不斷重試保證所有的步驟都成功,要么回滾到以前的服務(wù)調(diào)用。
因此我們可以對(duì)業(yè)務(wù)補(bǔ)償?shù)倪^程進(jìn)行一個(gè)定義,即當(dāng)某個(gè)操作發(fā)生了異常時(shí),如何通過內(nèi)部機(jī)制將這個(gè)異常產(chǎn)生的「不一致」?fàn)顟B(tài)消除掉。
2、業(yè)務(wù)補(bǔ)償設(shè)計(jì)的實(shí)現(xiàn)方式
業(yè)務(wù)補(bǔ)償設(shè)計(jì)的實(shí)現(xiàn)方式主要可分為兩種:
回滾(事務(wù)補(bǔ)償) ,逆向操作,回滾業(yè)務(wù)流程,意味著放棄,當(dāng)前操作必然會(huì)失敗;
重試 ,正向操作,努力地把一個(gè)業(yè)務(wù)流程執(zhí)行完成,代表著還有成功的機(jī)會(huì)。
一般來說,業(yè)務(wù)的事務(wù)補(bǔ)償都是需要一個(gè)工作流引擎的。這個(gè)工作流引擎把各式各樣的服務(wù)給串聯(lián)在一起,并在工作流上做相應(yīng)的業(yè)務(wù)補(bǔ)償,整個(gè)過程設(shè)計(jì)成為最終一致性的。
Ps:因?yàn)椤秆a(bǔ)償」已經(jīng)是一個(gè)額外流程了,既然能夠走這個(gè)額外流程,說明時(shí)效性并不是第一考慮的因素。所以做補(bǔ)償?shù)暮诵囊c(diǎn)是:寧可慢,不可錯(cuò)。
二、關(guān)于回滾
“回滾” 是指當(dāng)程序或數(shù)據(jù)出錯(cuò)時(shí),將程序或數(shù)據(jù)恢復(fù)到最近的一個(gè)正確版本的行為。在分布式業(yè)務(wù)補(bǔ)償設(shè)計(jì)到的回滾則是通過事務(wù)補(bǔ)償?shù)姆绞剑氐椒?wù)調(diào)用以前的狀態(tài)。
1、顯示回滾
回滾一般可分為 2 種模式:
顯式回滾 ;調(diào)用逆向接口,進(jìn)行上一次操作的反操作,或者取消上一次還沒有完成的操作(須鎖定資源);
隱式回滾 :隱式回滾意味著這個(gè)回滾動(dòng)作你不需要進(jìn)行額外處理,往往是由下游提供了失敗處理機(jī)制的。
最常見的就是「顯式回滾」。這個(gè)方案無(wú)非就是做 2 個(gè)事情:
首先要確定失敗的步驟和狀態(tài),從而確定需要回滾的范圍。一個(gè)業(yè)務(wù)的流程,往往在設(shè)計(jì)之初就制定好了,所以確定回滾的范圍比較容易。但這里唯一需要注意的一點(diǎn)就是:如果在一個(gè)業(yè)務(wù)處理中涉及到的服務(wù)并不是都提供了「回滾接口」,那么在編排服務(wù)時(shí)應(yīng)該把提供「回滾接口」的服務(wù)放在前面,這樣當(dāng)后面的工作服務(wù)錯(cuò)誤時(shí)還有機(jī)會(huì)「回滾」。
其次要能提供「回滾」操作使用到的業(yè)務(wù)數(shù)據(jù)。「回滾」時(shí)提供的數(shù)據(jù)越多,越有益于程序的健壯性。因?yàn)槌绦蚩梢栽谑盏健富貪L」操作的時(shí)候可以做業(yè)務(wù)的檢查,比如檢查賬戶是否相等,金額是否一致等等。
2、回滾的實(shí)現(xiàn)方式
對(duì)于跨庫(kù)的事務(wù),比較常見的解決方案有:兩階段提交、三階段提交(ACID)但是這 2 種方式,在高可用的架構(gòu)中一般都不可取,因?yàn)榭鐜?kù)鎖表會(huì)消耗很大的性能。
高可用的架構(gòu)中一般不會(huì)要求強(qiáng)一致性,只要達(dá)到最終的一致性就可以了。可以考慮:事務(wù)表、消息隊(duì)列、補(bǔ)償機(jī)制、TCC 模式(占位 / 確認(rèn)或取消)、Sagas模式(拆分事務(wù) + 補(bǔ)償機(jī)制)來實(shí)現(xiàn)最終的一致性。
三、關(guān)于重試
“重試” 的語(yǔ)義是我們認(rèn)為這個(gè)故障是暫時(shí)的,而不是永久的,所以,我們會(huì)去重試。這個(gè)操作最大的好處就是不需要提供額外的逆向接口。這對(duì)于代碼的維護(hù)和長(zhǎng)期開發(fā)的成本有優(yōu)勢(shì),而且業(yè)務(wù)是變化的。逆向接口也需要變化。所以更多時(shí)候可以考慮重試。
1、重試的使用場(chǎng)景
相較于回滾,重試使用的場(chǎng)景要少一些:下游系統(tǒng)返回請(qǐng)求超時(shí),被限流中等臨時(shí)狀態(tài)的時(shí)候,我們就可以考慮重試了。而如果是返回余額不足,無(wú)權(quán)限的明確業(yè)務(wù)錯(cuò)誤,就不需要重試。一些中間件或者 RPC 框架,返回 503,404 這種沒有預(yù)期恢復(fù)時(shí)間的錯(cuò)誤,也不需要重試了。
2、重試策略
重試的時(shí)間和重試的次數(shù)。這種在不同的情況下要有不同的考量,主流的重試策略主要是以下幾種:
策略 1 - 立即重試 :有時(shí)候故障是暫時(shí)性的,可能因?yàn)?a target="_blank">網(wǎng)絡(luò)數(shù)據(jù)包沖突或者硬件組件高峰流量等事件造成的,在這種情況下,適合立即重試的操作。不過立即重試的操作不應(yīng)該超過一次,如果立即重試失敗,應(yīng)該改用其他策略;
策略 2 - 固定間隔 :這個(gè)很好理解,比如每隔 5 分鐘重試一次。PS:策略 1 和策略 2 多用于前端系統(tǒng)的交互操作中;
策略 3 - 增量間隔 :每一次的重試間隔時(shí)間增量遞增。比如,第一次 0 秒、第二次 5 秒、第三次 10 秒這樣,使得失敗次數(shù)越多的重試請(qǐng)求優(yōu)先級(jí)排到越后面,給新進(jìn)入的重試請(qǐng)求讓路;
return(retryCount-1)*incrementInterval;
策略 4 - 指數(shù)間隔: 每一次的重試間隔呈指數(shù)級(jí)增加。和增量間隔一樣,都是想讓失敗次數(shù)越多的重試請(qǐng)求優(yōu)先級(jí)排到越后面,只不過這個(gè)方案的增長(zhǎng)幅度更大一些;
return2^retryCount;
策略 5 - 全抖動(dòng): 在遞增的基礎(chǔ)上,增加隨機(jī)性(可以把其中的指數(shù)增長(zhǎng)部分替換成增量增長(zhǎng)。)適用于將某一時(shí)刻集中產(chǎn)生的大量重試請(qǐng)求進(jìn)行壓力分散的場(chǎng)景;
returnrandom(0,2^retryCount);
策略 6 - 等抖動(dòng): 在「指數(shù)間隔」和「全抖動(dòng)」之間尋求一個(gè)中庸的方案,降低隨機(jī)性的作用。適用場(chǎng)景和「全抖動(dòng)」一樣。
intbaseNum=2^retryCount; returnbaseNum+random(0,baseNum);
策略 - 3、4、5、6 的表現(xiàn)情況大致是這樣(x軸為重試次數(shù)):
3、重試時(shí)的注意事項(xiàng)
首先對(duì)于需要重試的接口,是需要做成冪等性的,即不能因?yàn)榉?wù)的多次調(diào)用而導(dǎo)致業(yè)務(wù)數(shù)據(jù)的累計(jì)增加或減少。
滿足「冪等性」其實(shí)就是需要想辦法識(shí)別重復(fù)的請(qǐng)求,并且將其過濾掉。思路就是:
給每個(gè)請(qǐng)求定義一個(gè)唯一標(biāo)識(shí)。
在進(jìn)行「重試」的時(shí)候判斷這個(gè)請(qǐng)求是否已經(jīng)被執(zhí)行或者正在被執(zhí)行,如果是則拋棄該請(qǐng)求。
Ps:此外重試特別適合在高負(fù)載情況下被降級(jí),當(dāng)然也應(yīng)當(dāng)受到限流和熔斷機(jī)制的影響。當(dāng)重試的“矛”與限流和熔斷的“盾”搭配使用,效果才是最好。
四、業(yè)務(wù)補(bǔ)償機(jī)制的注意事項(xiàng)
1、ACID 還是 BASE
ACID 和 BASE 是分布式系統(tǒng)中兩種不同級(jí)別的一致性理論,在分布式系統(tǒng)中,ACID有更強(qiáng)的一致性,但可伸縮性非常差,僅在必要時(shí)使用;BASE的一致性較弱,但有很好的可伸縮性,還可以異步批量處理;大多數(shù)分布式事務(wù)適合 BASE。
而在重試或回滾的場(chǎng)景下,我們一般不會(huì)要求強(qiáng)一致性,只要保證最終一致性就可以了!
2、業(yè)務(wù)補(bǔ)償設(shè)計(jì)的注意事項(xiàng)
業(yè)務(wù)補(bǔ)償設(shè)計(jì)的注意事項(xiàng):
因?yàn)橐岩粋€(gè)業(yè)務(wù)流程執(zhí)行完成,需要這個(gè)流程中所涉及的服務(wù)方支持冪等性。并且在上游有重試機(jī)制;
我們需要小心維護(hù)和監(jiān)控整個(gè)過程的狀態(tài),所以,千萬(wàn)不要把這些狀態(tài)放到不同的組件中,最好是一個(gè)業(yè)務(wù)流程的控制方來做這個(gè)事,也就是一個(gè)工作流引擎。所以,這個(gè)工作流引擎是需要高可用和穩(wěn)定的;
補(bǔ)償?shù)臉I(yè)務(wù)邏輯和流程不一定非得是嚴(yán)格反向操作。有時(shí)候可以并行,有時(shí)候,可能會(huì)更簡(jiǎn)單。總之,設(shè)計(jì)業(yè)務(wù)正向流程的時(shí)候,也需要設(shè)計(jì)業(yè)務(wù)的反向補(bǔ)償流程;
我們要清楚地知道,業(yè)務(wù)補(bǔ)償?shù)臉I(yè)務(wù)邏輯是強(qiáng)業(yè)務(wù)相關(guān)的,很難做成通用的;
下層的業(yè)務(wù)方最好提供短期的資源預(yù)留機(jī)制。就像電商中的把貨品的庫(kù)存預(yù)先占住等待用戶在 15 分鐘內(nèi)支付。如果沒有收到用戶的支付,則釋放庫(kù)存。然后回滾到之前的下單操作,等待用戶重新下單。
審核編輯:劉清
-
數(shù)據(jù)傳輸
+關(guān)注
關(guān)注
9文章
1923瀏覽量
64685 -
交換機(jī)
+關(guān)注
關(guān)注
21文章
2646瀏覽量
99805 -
路由器
+關(guān)注
關(guān)注
22文章
3737瀏覽量
114019 -
DNS
+關(guān)注
關(guān)注
0文章
219瀏覽量
19877
原文標(biāo)題:淺談分布式系統(tǒng)中的補(bǔ)償機(jī)制設(shè)計(jì)問題
文章出處:【微信號(hào):芋道源碼,微信公眾號(hào):芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論