【博文目錄>>>】
補償交易模式
如果一個或多個步驟失敗，則撤消由一系列執行的工作的步驟組成，這些步驟一起定義最終一致的操作。遵循最終一致性模型的操作通常可在實現複雜業務流程和工作流的雲託管應用程序中找到。
背景與問題
運行在雲中的應用程序經常修改數據。這些數據可以分佈在各種地理位置的各種數據源上。爲了在這樣的分佈式環境中避免爭用和提高性能，應用程序不應該試圖提供強大的事務一致性。相反，應用程序應該實現最終一致性。在該模型中，典型的業務操作由一系列自治步驟組成。在執行這些步驟時，系統狀態的總體視圖可能是不一致的，但是當操作完成並且所有步驟都已經執行時，系統應該再次變得一致。
注
這個數據一致性入門提供有關分佈式事務不能很好地擴展的更多信息，以及支持最終一致性模型的原則。
在最終一致性模型中，一個重大的挑戰是如何處理一個已經無法恢復的步驟。在這種情況下，可能需要撤消操作中前面步驟完成的所有工作。但是，不能簡單地回滾數據，因爲應用程序的其他併發實例可能已經更改了它。即使在數據未被併發實例更改的情況下，取消步驟也不可能只是恢復原始狀態的問題。可能有必要應用各種特定於業務的規則(參見示例部分中描述的旅遊網站)。
如果實現最終一致性的操作跨越多個異構數據存儲，則取消此操作中的步驟將需要依次訪問每個數據存儲。必須可靠地撤消在每個數據存儲中執行的工作，以防止系統保持不一致。
並非所有受實現最終一致性的操作影響的數據都可能保存在數據庫中。在面向服務的體系結構(ServiceOrientedArchitecture，SOA)環境中，操作可能會調用服務中的操作，並導致該服務保持的狀態發生變化。若要撤消操作，還必須撤消此狀態更改。這可能涉及再次調用服務，並執行另一個逆轉第一個服務效果的操作。
解決方案
實現補償事務。補償事務中的步驟必須撤消原始操作中步驟的效果。補償事務可能無法簡單地將當前狀態替換爲系統在操作開始時所處的狀態，因爲這種方法可能會覆蓋應用程序的其他併發實例所做的更改。相反，它必須是一個考慮到併發實例所做的任何工作的智能過程。這個過程通常是特定於應用程序的，由原始操作所執行的工作性質驅動。
實現需要補償的最終一致操作的一種常見方法是使用工作流。隨着原始操作的進行，系統記錄關於每個步驟的信息，以及如何撤消該步驟所執行的工作。如果操作在任何時候失敗，工作流將在它完成的步驟中回滾，並執行逆轉每個步驟的工作。請注意，補償事務可能不必按照與原始操作完全相反的順序撤消工作，並且可能並行執行一些撤消步驟。
注
這種方法類似於Sagas戰略。有關此策略的說明可在克萊門斯·維斯特斯的博客上找到.
補償事務本身就是一個最終一致的操作，它也可能失敗。系統應該能夠在故障點恢復補償事務並繼續進行。可能需要重複一個失敗的步驟，因此補償事務中的步驟應該定義爲冪等命令。有關冪等性的詳細信息，請參閱冪等模式喬納森·奧利弗的博客上。
在某些情況下，除非通過人工干預，否則可能無法從失敗的步驟中恢復。在這種情況下，系統應該發出警報，並儘可能多地提供有關故障原因的信息。
問題和思考
在決定如何實現此模式時，請考慮以下幾點：
- 要確定實現最終一致性的操作中的步驟何時失敗，可能並不容易。一個步驟可能不會立即失敗，但它可能會阻止。可能有必要實施某種形式的超時機制。
- 補償邏輯不易推廣。補償事務是特定於應用程序的；它依賴於具有足夠信息的應用程序能夠撤消失敗操作中每個步驟的影響。
- 您應該將補償事務中的步驟定義爲冪等命令。如果補償事務本身失敗，則可以重複這些步驟。
- 處理原始操作中的步驟和補償事務的基礎結構必須具有彈性。它不能丟失補償失敗步驟所需的信息，並且必須能夠可靠地監視補償邏輯的進展。
- 補償事務不一定將系統中的數據返回到原始操作開始時所處的狀態。相反，它補償操作失敗前成功完成的步驟所執行的工作。
- 補償事務中步驟的順序不一定是與原始操作中的步驟相反的鏡像。例如，一個數據存儲可能比另一個數據存儲更敏感，因此應該首先執行補償事務中撤消對此存儲的更改的步驟。
- 在每個完成操作所需的資源上放置一個基於短期超時的鎖，並提前獲得這些資源，可以幫助增加整個活動成功的可能性。只有在獲得所有資源之後才能完成這項工作。所有操作必須在鎖過期前完成。
- 考慮使用比通常更寬容的重試邏輯來最小化觸發補償事務的失敗。如果操作中實現最終一致性的步驟失敗，請嘗試將故障作爲瞬態異常處理並重復該步驟。只有在步驟重複失敗或無法恢復時，才中止操作並啓動補償事務。
注
實施補償交易的許多挑戰和問題與實現最終一致性的挑戰和問題相同。有關實現最終一致性的考慮事項，請參見數據一致性入門瞭解更多信息。
何時使用此模式
此模式僅用於如果操作失敗必須撤消的操作。如果可能，設計解決方案以避免需要補償事務的複雜性(有關更多信息，請參見數據一致性入門).
例子
旅遊網站使客戶能夠預訂行程。一個單一的行程可以包括一系列的航班和酒店。客戶從西雅圖到倫敦，然後再到巴黎，在創建行程時可以執行以下步驟：
- 預訂從西雅圖到倫敦的F1航班的座位。
- 預訂從倫敦到巴黎的F2次航班的座位。
- 預訂從巴黎到西雅圖的F3航班的座位。
- 在倫敦H1酒店預訂房間。
- 預訂巴黎H2酒店的房間。
這些步驟構成了最終一致的操作，儘管每個步驟本身本質上都是一個單獨的原子操作。因此，在執行這些步驟的同時，系統還必須記錄撤銷每個步驟所需的計數器操作，以防客戶決定取消行程。如果有必要，執行計數器操作所需的步驟可以作爲補償事務運行。
注意，補償事務中的步驟可能不是與原始步驟完全相反的步驟，補償事務中每個步驟中的邏輯必須考慮到任何特定於業務的規則。例如，“取消預訂”航班上的座位可能不能使顧客獲得全額退款。
圖1-生成補償事務以撤消長期運行的事務以預訂旅行日程
注
補償事務中的步驟可能並行執行，這取決於您如何爲每個步驟設計補償邏輯。
在許多業務解決方案中，單個步驟的失敗並不總是需要使用補償事務來回滾系統。例如，如果在旅行網站場景中預訂了F1、F2和F3航班後，客戶無法預訂H1酒店的房間，則最好在同一城市的另一家酒店爲客戶提供房間，而不是取消航班。客戶仍然可以選擇取消(在這種情況下，補償事務將運行並取消對F1、F2和F3航班的預訂)，但此決定應由客戶而不是由系統作出。
相關模式和指導
在實施這一模式時，下列模式和指導也可能相關：
- 數據一致性入門。補償事務模式經常用於撤消實現最終一致性模型的操作。本入門提供更多關於最終一致性的好處和權衡的信息。
- 調度程序-代理-監控模式。此模式描述瞭如何實現執行利用分佈式服務和資源的業務操作的彈性系統。在某些情況下，可能需要使用補償事務撤消操作執行的工作。
- 重試模式。補償事務的執行成本可能很高，並且可能通過按照重試模式實現重試失敗操作的有效策略來最小化它們的使用。
原文鏈接
https://docs.microsoft.com/en-us/previous-versions/msp-n-p/dn589804%28v%3dpandp.10%29