分散式系統關注點——99%的人都能看懂的「補償」以及最佳實踐
如果這是第二次看到我的文章，歡迎訂閱我的公眾號（跨界架構師）喲~
本文長度為4229字，建議閱讀11分鐘。
這是本系列中既「資料一致性」後的第二章節——「高可用」的完結篇。
前面幾篇中z哥跟你聊了聊做「高可用」的意義，以及如何做「負載均衡」和「高可用三劍客」（熔斷、限流、降級，文末會附上前文連線：））。這次，我們來聊一聊在保證對外高可用的同時，憋出的“內傷”該如何通過「補償」機制來自行消化。
一、「補償」機制的意義？
以電商的購物場景為例：
客戶端 ---->購物車微服務 ---->訂單微服務 ----> 支付微服務。
這種呼叫鏈非常普遍。
那麼為什麼需要考慮補償機制呢？
正如之前幾篇文章所說，一次跨機器的通訊可能會經過DNS 服務，網絡卡、交換機、路由器、負載均衡等裝置，這些裝置都不一定是一直穩定的，在資料傳輸的整個過程中，只要任意一個環節出錯，都會導致問題的產生。
而在分散式場景中，一個完整的業務又是由多次跨機器通訊組成的，所以產生問題的概率成倍數增加。
但是，這些問題並不完全代表真正的系統無法處理請求，所以我們應當儘可能的自動消化掉這些異常。
可能你會問，之前也看到過「補償」和「事務補償」或者「重試」，它們之間的關係是什麼？
你其實可以不用太糾結這些名字，從目的來說都是一樣的。就是一旦某個操作發生了異常，如何通過內部機制將這個異常產生的「不一致」狀態消除掉
題外話：在Z哥看來，不管用什麼方式，只要通過額外的方式解決了問題都可以理解為是「補償」，所以「事務補償」和「重試」都是「補償」的子集。前者是一個逆向操作，而後者則是一個正向操作。
只是從結果來看，兩者的意義不同。「事務補償」意味著“放棄”，當前操作必然會失敗。
事務補償
「重試」則還有處理成功的機會。這兩種方式分別適用於不同的場景。
重試
因為「補償」已經是一個額外流程了，既然能夠走這個額外流程，說明時效性並不是第一考慮的因素，所以做補償的核心要點是：寧可慢，不可錯。
因此，不要草率的就確定了補償的實施方案，需要謹慎的評估。雖說錯誤無法100%避免，但是抱著這樣的一個心態或多或少可以減少一些錯誤的發生。
二、「補償」該怎麼做？
做「補償」的主流方式就前面提到的「事務補償」和「重試」，以下會被稱作「回滾」和「重試」。
我們先來聊聊「回滾」。相比「重試」，它邏輯上更簡單一些。
「回滾」
Z哥將回滾分為2種模式，一種叫「顯式回滾」（呼叫逆向介面），一種叫「隱式回滾」（無需呼叫逆向介面）。
最常見的就是「顯式回滾」。這個方案無非就是做2個事情：
首先要確定失敗的步驟和狀態，從而確定需要回滾的範圍。一個業務的流程，往往在設計之初就制定好了，所以確定回滾的範圍比較容易。但這裡唯一需要注意的一點就是：如果在一個業務處理中涉及到的服務並不是都提供了「回滾介面」，那麼在編排服務時應該把提供「回滾介面」的服務放在前面，這樣當後面的工作服務錯誤時還有機會「回滾」。
其次要能提供「回滾」操作使用到的業務資料。「回滾」時提供的資料越多，越有益於程式的健壯性。因為程式可以在收到「回滾」操作的時候可以做業務的檢查，比如檢查賬戶是否相等，金額是否一致等等。
由於這個中間狀態的資料結構和資料大小並不固定，所以Z哥建議你在實現這點的時候可以將相關的資料序列化成一個json，然後存放到一個nosql型別的儲存中。
「隱式回滾」相對來說運用場景比較少。它意味著這個回滾動作你不需要進行額外處理，下游服務內部有類似“預佔”並且“超時失效”的機制的。例如：
電商場景中，會將訂單中的商品先預佔庫存，等待使用者在 15 分鐘內支付。如果沒有收到使用者的支付，則釋放庫存。
下面聊聊可以有很多玩法，也更容易陷入坑裡的「重試」。
「重試」
「重試」最大的好處在於，業務系統可以不需要提供「逆向介面」，這是一個對長期開發成本特別大的利好，畢竟業務是天天在變的。所以，在可能的情況下，應該優先考慮使用「重試」。
不過，相比「回滾」來說「重試」的適用場景更少一些，所以我們第一步首先要判斷，當前場景是否適合「重試」。比如：
-
下游系統返回「請求超時」、「被限流中」等臨時狀態的時候，我們可以考慮重試
-
而如果是返回“餘額不足”、“無許可權”等明確無法繼續的業務性錯誤的時候就不需要重試了
-
一些中介軟體或者rpc框架中返回Http503、404等沒有何時恢復的預期的時候，也不需要重試
如果確定要進行「重試」，我們還需要選定一個合適的「重試策略」。主流的「重試策略」主要是以下幾種。
策略1.立即重試。有時故障是候暫時性，可能是因網路資料包衝突或硬體元件流量高峰等事件造成的。在此情況下，適合立即重試操作。不過，立即重試次數不應超過一次，如果立即重試失敗，應改用其它的策略。
策略2.固定間隔。應用程式每次嘗試的間隔時間相同。 這個好理解，例如，固定每 3 秒重試操作。（以下所有示例程式碼中的具體的數字僅供參考。）
策略1和策略2多用於前端系統的互動式操作中。
策略3.增量間隔。每一次的重試間隔時間增量遞增。比如，第一次0秒、第二次3秒、第三次6秒，9、12、15這樣。
return (retryCount - 1) * incrementInterval;
使得失敗次數越多的重試請求優先順序排到越後面，給新進入的重試請求讓道。
策略4.指數間隔。每一次的重試間隔呈指數級增加。和增量間隔“殊途同歸”，都是想讓失敗次數越多的重試請求優先順序排到越後面，只不過這個方案的增長幅度更大一些。
return 2 ^ retryCount;
策略5.全抖動。在遞增的基礎上，增加隨機性（可以把其中的指數增長部分替換成增量增長。）。適用於將某一時刻集中產生的大量重試請求進行壓力分散的場景。
return random(0 , 2 ^ retryCount);
策略6.等抖動。在「指數間隔」和「全抖動」之間尋求一箇中庸的方案，降低隨機性的作用。適用場景和「全抖動」一樣。
var baseNum = 2 ^ retryCount;return baseNum + random(0 , baseNum);
3、4、5、6策略的表現情況大致是這樣。(x軸為重試次數)
為什麼說「重試」有坑呢？
正如前面聊到的那樣，出於對開發成本考慮，你在做「重試」的時候可能是複用的常規呼叫的介面。那麼此時就不得不提一個「冪等性」問題。
如果實現「重試」選用的技術方案不能100%確保不會重複發起重試，那麼「冪等性」問題是一個必須要考慮的問題。哪怕技術方案可以確保100%不會重複發起重試，出於對意外情況的考量，儘量也考慮一下「冪等性」問題。
冪等性：不管對程式發起幾次重複呼叫，程式表現的狀態（所有相關的資料變化）與呼叫一次的結果是一致的話，就是保證了冪等性。
這意味著可以根據需要重複或重試操作，而不會導致意外的影響。對於非冪等操作，演算法可能必須跟蹤操作是否已經執行。
所以，一旦某個功能支援「重試」，那麼整個鏈路上的介面都需要考慮冪等性問題，不能因為服務的多次呼叫而導致業務資料的累計增加或減少。
滿足「冪等性」其實就是需要想辦法識別重複的請求，並且將其過濾掉。思路就是：
-
給每個請求定義一個唯一標識。
-
在進行「重試」的時候判斷這個請求是否已經被執行或者正在被執行，如果是則拋棄該請求。
第1點，我們可以使用一個全域性唯一id生成器或者生成服務（可以擴充套件閱讀，分散式系統中的必備良藥 —— 全域性唯一單據號生成）。 或者簡單粗暴一些，使用官方類庫自帶的Guid、uuid之類的也行。
然後通過rpc框架在發起呼叫的客戶端中，對每個請求增加一個唯一標識的欄位進行賦值。
第2點，我們可以在服務端通過Aop的方式切入到實際的處理邏輯程式碼之前和之後，一起配合做驗證。
大致的程式碼思路如下。
【方法執行前】if(isExistLog(requestId)){ //1.判斷請求是否已被接收過。 對應序號3
var lastResult = getLastResult(); //2.獲取用於判斷之前的請求是否已經處理完成。 對應序號4
if(lastResult == null){
var result = waitResult(); //掛起等待處理完成
return result;
}
else{
return lastResult;
}
}
else{
log(requestId); //3.記錄該請求已接收
}
//do something..
【方法執行後】
logResult(requestId, result); //4.將結果也更新一下。
如果「補償」這個工作是通過MQ來進行的話，這事就可以直接在對接MQ所封裝的SDK中做。在生產端賦值全域性唯一標識，在消費端通過唯一標識消重。
三、「重試」的最佳實踐
再聊一些Z哥積累的最佳實踐吧（劃重點：）），都是針對「重試」的，的確這也是工作中最常用的方案。
「重試」特別適合在高負載情況下被「降級」，當然也應當受到「限流」和「熔斷」機制的影響。當「重試」的“矛”與「限流」和「熔斷」的“盾”搭配使用，效果才是最好。
需要衡量增加補償機制的投入產出比。一些不是很重要的問題時，應該「快速失敗」而不是「重試」。
過度積極的重試策略（例如間隔太短或重試次數過多）會對下游服務造成不利影響，這點一定要注意。
一定要給「重試」制定一個終止策略。
當回滾的過程很困難或代價很大的情況下，可以接受很長的間隔及大量的重試次數，DDD中經常被提到的「saga」模式其實也是這樣的思路。不過，前提是不會因為保留或鎖定稀缺資源而阻止其他操作（比如1、2、3、4、5幾個序列操作。由於2一直沒處理完成導致3、4、5沒法繼續進行）。
四、總結
這篇我們先聊了下做「補償」的意義，以及做補償的2個方式「回滾」和「重試」的實現思路。
然後，提醒你要注意「重試」的時候需要考慮冪等性問題，並且z哥也給出了一個解決思路。
最後，分享了幾個z哥總結的針對「重試」的最佳實踐。
希望對你有所幫助。
Question：
你之前有哪些時候是通過自己人工來做「補償」的經歷嗎？歡迎吐槽～
z哥自己就有多次熬到半夜才把“意外”造成的混亂清理乾淨，刻骨銘心啊。
相關文章：
作者：Zachary
出處：https://www.cnblogs.com/Zachary-Fan/p/compensation.html
關於作者：張帆（Zachary，個人微訊號：Zachary-ZF）。堅持用心打磨每一篇高質量原創。歡迎關注我的公眾號（跨界架構師）哦~。
定期發表原創內容：架構設計丨分散式系統丨產品丨運營丨一些思考。