（三）—— 補償交易模式

云計算設(shè)計模式（三）——補償交易模式

撤消由一系列步驟，它們共同限定了最終一致性操作中，如果一個或多個步驟失敗執(zhí)行的工作。按照最終一致性模型，業(yè)務(wù)實現(xiàn)復(fù)雜的業(yè)務(wù)流程和工作流的云托管的應(yīng)用程序中很常見。

背景和問題

在云中運行的應(yīng)用程序頻繁修改數(shù)據(jù)。此數(shù)據(jù)可跨在各種地理位置的所保持的數(shù)據(jù)源的一個品種傳播。為了避免爭用，并提高在分布式環(huán)境中，例如這樣的性能，應(yīng)用程序不應(yīng)該試圖提供強事務(wù)一致性。相反，應(yīng)用程序應(yīng)該實現(xiàn)最終一致性。在該模型中，一個典型的業(yè)務(wù)操作由一系列的獨立的步驟。而正在執(zhí)行這些步驟的系統(tǒng)狀態(tài)的整體圖可能是不一致的，但是，當(dāng)操作完成并且所有步驟都被執(zhí)行，系統(tǒng)應(yīng)該重新變得一致。

注意

數(shù)據(jù)的一致性提供了入門為什么分布式事務(wù)不能很好地擴展更多的信息，并且鞏固了最終一致性模型的原則。

在最終一致性模型的一個顯著的挑戰(zhàn)是如何處理失敗無可挽回的一步。在這種情況下，可能需要撤消所有通過的操作中的前面的步驟完成的工作。然而，數(shù)據(jù)不能簡單地被回滾，因為應(yīng)用程序的其它并發(fā)實例可能已經(jīng)改變，因為它。即使在數(shù)據(jù)沒有被通過一并發(fā)實例變更的情況下，撤消一個步驟可能不是簡單地恢復(fù)原始狀態(tài)的問題。可能需要應(yīng)用不同的業(yè)務(wù)特定的規(guī)則（參見實施例部分中描述的旅行網(wǎng)站）。

如果實現(xiàn)最終一致性操作跨越多個異構(gòu)數(shù)據(jù)存儲，解開在這樣的操作中的步驟將需要訪問的每個數(shù)據(jù)存儲區(qū)中的轉(zhuǎn)彎。在每一個數(shù)據(jù)存儲區(qū)執(zhí)行的工作必須可靠地復(fù)原到防止系統(tǒng)其余不一致。

不受實現(xiàn)最終一致性的操作的所有數(shù)據(jù)可能會在數(shù)據(jù)庫中進(jìn)行。在面向服務(wù)的架構(gòu)（SOA）環(huán)境中的操作可能會調(diào)用一個服務(wù)動作，并導(dǎo)致由該服務(wù)保持狀態(tài)的變化。要撤消的操作，這種狀態(tài)的改變也必須是百廢待興。這可能涉及再次調(diào)用服務(wù)并執(zhí)行該反轉(zhuǎn)第一的影響另一個動作。

解決方案

落實補償事務(wù)。在一個補償事務(wù)的步驟必須撤消的原始操作的步驟的影響。補償事務(wù)可能無法簡單地與國家的制度在運行，因為這種方法可能會覆蓋由應(yīng)用程序的其他并發(fā)實例所做的更改開始取代目前的狀態(tài)。相反，它必須是一個聰明的過程中，考慮到并發(fā)情況下進(jìn)行的任何工作。這個過程通常是應(yīng)用程序特定的，由原始操作所執(zhí)行的工作的性質(zhì)來驅(qū)動。

一種常見的方法來實現(xiàn)的，最終一致的操作，需要補償?shù)氖鞘褂玫墓ぷ髁?。由于原來的動作的進(jìn)行，系統(tǒng)記錄每個步驟，以及如何通過該步驟完成的工作可以撤消信息。如果操作失敗，在任何時候，在工作流倒卷回通過它已經(jīng)完成的步驟，并執(zhí)行反轉(zhuǎn)每個步驟的工作。注意，補償事務(wù)可能沒有撤消的原始操作的精確鏡面相反的順序工作，并且它可能會執(zhí)行一些并行撤銷步驟。

注意

這種方法類似于英雄傳奇策略。這一戰(zhàn)略的描述是克萊門斯 Vasters 的博客在網(wǎng)上提供。

補償事務(wù)本身是一個最終一致的操作，它也可能會失敗。該系統(tǒng)應(yīng)能夠恢復(fù)補償事務(wù)在故障點并繼續(xù)?？赡苡斜匾貜?fù)發(fā)生故障的步驟，所以在補償事務(wù)的步驟應(yīng)該被定義為冪等的命令。有關(guān)冪等的詳細(xì)信息，請參閱喬納森·奧利弗的博客冪等模式??。

在某些情況下，可能無法從該已失敗，除非通過人工干預(yù)的步驟中恢復(fù)。在這種情況下，系統(tǒng)應(yīng)發(fā)出警報，并提供盡可能多的信息盡可能了解失敗的原因。

問題和注意事項

在決定如何實現(xiàn)這個模式時，請考慮以下幾點：

• 它可能不容易確定何時在實現(xiàn)最終一致性的動作的步驟已經(jīng)失敗。一個步驟可能不會立即失敗，而是它可以阻止。可能有必要實現(xiàn)某種形式的超時機制。
• 補償邏輯不容易推廣。補償事務(wù)是特定于應(yīng)用程序;它依賴于具有足夠的信息，以便能夠撤消在一個失敗的操作的每個步驟的效果的應(yīng)用。
• 您應(yīng)該定義的步驟在補償事務(wù)的冪等命令。這使得，如果補償事務(wù)本身不能被重復(fù)的步驟。
• 處理中原始操作的步驟，以及所述補償事務(wù)的基礎(chǔ)設(shè)施，必須是有彈性的。它一定不能失去，以補償發(fā)生故障的步驟所需要的信息，而且它必須能夠可靠地監(jiān)視補償邏輯的進(jìn)度。
• 一個補償事務(wù)并不一定在系統(tǒng)中返回數(shù)據(jù)的狀態(tài)是在原操作的開始。相反，它補償了由該成功完成操作失敗之前的步驟中執(zhí)行的工作。
• 在補償事務(wù)中的步驟的順序并不一定是反射鏡相反的，在原來的操作的步驟。例如，一個數(shù)據(jù)存儲可以是不一致比另一個更敏感，從而撤消更改到該商店中的補償事務(wù)的步驟應(yīng)首先發(fā)生。
• 在完成操作所需的每個資源放置一個短期的基于超時的鎖，并提前獲得這些資源，可以幫助增加的可能性，整體活動將取得成功。這項工作應(yīng)執(zhí)行的所有資源都被收購之后。所有操作必須完成的鎖到期之前。
• 考慮使用重試邏輯比平常更多的寬容，盡量減少觸發(fā)補償事務(wù)失敗。如果一個操作步驟，實現(xiàn)最終一致性失敗，請嘗試處理故障為一過性異常，并重復(fù)上述步驟。只有放棄操作，如果一個步驟反復(fù)或無可挽回地失敗，啟動補償事務(wù)。

注意： 很多的挑戰(zhàn)和實施補償事務(wù)的問題是一樣關(guān)心實現(xiàn)最終一致性。請參見注意事項實現(xiàn)了數(shù)據(jù)的一致性入門最終一致性的更多信息。

當(dāng)使用這個模式

使用此模式僅適用于如果他們失敗，必須撤銷的操作。如果可能的話，設(shè)計解決方案，避免了需要補償事務(wù)的復(fù)雜性（有關(guān)詳細(xì)信息，請參閱數(shù)據(jù)一致性底漆）。

例子

一個旅游網(wǎng)站，使客戶預(yù)訂行程。一個單一的行程可包括一系列航班和酒店的。一位顧客旅行從西雅圖到倫敦及巴黎可以創(chuàng)建一個行程時，請執(zhí)行以下步驟：

1.預(yù)訂一個座位上的 F1 航班從西雅圖飛往倫敦。

2.預(yù)訂一個座位上的 F2 航班從倫敦到巴黎。

3.書本占座 F3 航班從巴黎飛往西雅圖。

4.預(yù)訂的房間在倫敦酒店 H1。

5.預(yù)訂在巴黎一間客房的酒店 H2。

這些步驟構(gòu)成了最終一致的操作，雖然每一步基本上是在自己的權(quán)利單獨的原子操作。因此，以及在執(zhí)行這些步驟時，系統(tǒng)還必須記錄必要撤消各以防客戶決定取消行程步驟計數(shù)器的操作。必要執(zhí)行計數(shù)器操作步驟，然后可以作為一個補償事務(wù)如有必要運行。

請注意，在補償事務(wù)中的步驟可能不是原來的步驟完全相反，并且在補償事務(wù)的每個步驟必須考慮到任何特定于業(yè)務(wù)的邏輯規(guī)則。例如，“unbooking 取消預(yù)訂”座位上的飛行可能不是客戶有權(quán)向支付任何款項完成退款。

圖1 - 生成一個補償事務(wù)撤消一個長時間運行的事務(wù)預(yù)訂旅游行程

Note

它可能會在并行執(zhí)行的補償事務(wù)的步驟，這取決于你如何設(shè)計每一步的補償邏輯。

在許多商業(yè)解決方案，在單步的故障不總是必要軋制系統(tǒng)背面用補償事務(wù)。例如，具有在旅游網(wǎng)站的情況，客戶是無法預(yù)訂到酒店H1預(yù)訂航班 F1，F(xiàn)2 和 F3 的話，以后，最好是提供客戶在同一個城市的房間在不同的酒店而不是取消航班。客戶仍然可以選擇取消（在這種情況下，補償事務(wù)運行，并撤消作出關(guān)于航班 F1，F(xiàn)2 和 F3中的預(yù)訂），但這個決定應(yīng)該由客戶而不是由系統(tǒng)進(jìn)行。