Saga實現分布式事務的內容有有哪些

本篇內容介紹了“Saga實現分布式事務的內容有有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

隨著微服務架構的興起，越來越多的公司會在實際場景中遇到分布式事務的問題。特別是在金融應用場景，幾個跨進程的應用共同完成一個任務，就更離不開分布式事務的參與。而對于分布式事務而言，2PC、TCC也是經常被提到了，不過在面對長業務流程，并且很難進行TCC改造的場景，會選擇使用Saga分布式事務。Saga實現分布式事務的內容有：

1. Saga的分布式解決方案

2. Saga處理事務一致性

3. Saga分布式事務協調

4. Saga的分布式解決方案

隨著互聯網的快速發展，原來的單體應用已經很難支撐大流量高并發的請求了，因此軟件系統由原來的單體應用逐漸向分布式過度，如圖1所示，左邊的Web App  包含了UI和服務的模塊，在轉變以后會對應右邊的微服務架構，服務之間存在關聯地相互調用。

圖1 單體到分布式的系統架構過渡

在進行分布式部署之后，會存在多個服務共同完成一個事務操作，并且這些服務彼此都存在于不同的服務器或者網絡環境，服務之間需要通過網絡遠程協作完成事務稱之為分布式事務。例如：銀行轉賬業務、下單扣件庫存等。

在分布式事務場景下，如果對數據有強一致性要求，會在業務層上才去“兩階段提交”(2PC)的方案。

如果保證最終一致性的話可以采取TCC (Try Confirm  Cancel)模式。雖然TCC保證最終一致性的模式被業內廣泛使用，但是對于某些分布式事務場景，流程多、流程長、還可能要調用其它公司的服務。特別是對于不可控的服務(其他公司的服務)，這些服務無法遵循  TCC  開發模式，導致TCC模式的開發成本增高。體現在具體場景中，以金融核心的業務為代表(渠道層、產品層、集成層)，其特點是：流程多、流程長、調用不可控服務。同時也是應為流程長，事務邊界太長，加鎖時間長，使用TCC模式會影響并發性能。

鑒于此類業務場景的分布式事務處理，提出了Saga分布式處理模式。Saga是一種“長事務的解決方案”，更適合于“業務流程長、業務流程多”的場景。特別是針對參與事務的服務是遺留系統服務，此類服務無法提供TCC模式下的三個接口，就可以采用Saga模式。

其適用于的業務業務場景有，金融機構對接系統(需要對接外部系統)、渠道整合(流程長)、分布式架構服務等。其優勢是一階段提交本地事務，無鎖，高性能;參與者可異步執行，高吞吐;補償服務易于實現，因為一個更新操作的反向操作是比較容易理解的;當然其也存在缺點，就是不保證隔離性。

Saga處理事務一致性

1987年普林斯頓大學的Hector Garcia-Molina和Kenneth Salem發表了一篇Paper Sagas，講述的是如何處理long  lived  transaction(長活事務)。Saga是一個長活事務可被分解成可以交錯運行的子事務集合。其中每個子事務都是一個保持數據庫一致性的真實事務。

在這位老兄的論文中提到，每個Saga由一系列sub-transaction  Ti組成。每個Ti都有對應的補償動作Ci，補償動作用于撤銷Ti造成的結果。這里可以理解為，針對每一個分布式事務的每個執行操作或者是步驟都是一個  Ti，例如扣減庫存是T1、創建訂單是T2、支付服務是T3。那么針對每個Ti都對應一個補償動作Ci，例如回復庫存C1、訂單回滾C2、支付回滾C3。

Saga事務有兩種恢復策略：

向前恢復(forward recovery)，也就是“勇往直前”。

對于執行不通過的事務，會嘗試重試事務，這里有一個假設就是每個子事務最終都會成功。這種方式適用于必須要成功的場景，如圖2  所示，上面的圖例，子事務按照從左到右的順序執行，T1執行完畢以后T2 執行，然后是T3、T4、T5。

圖2 Saga事務執行的策略

事務恢復的順序也是按照：T1、T2、T3、T4、T5的方向進行，如果在執行T1的時候失敗了就重試T1，以此類推在哪個子事務執行時失敗了就執行哪個事務。因此叫做“勇往直前”。

向后恢復(backward  recovery)，在執行事務失敗時，補償所有已完成的事務，是“一退到底”的方式。如圖2所示，下面的圖例，子事務依舊從左往右執行，在執行到事務T3的時候，該事務執行失敗了，于是按照紅線的方向開始執行補償事務，先執行C3、然后是C2和C1，直到T0、T1、T2的補償事務C1、C2、C3都執行完畢。也就是回滾整個Saga的執行結果。

Saga分布式事務協調

上面介紹了Saga的概念和事務恢復方式，每個事務存在多個子事務，每個子事務都有一個補償事務，其在事務回滾的時候使用。由于子事務對應的操作在分布式的系統架構中會部署在不同的服務中，這些子事務為了完成共同的事務需要進行協同。

實際上在啟動一個Saga事務時，協調邏輯會告訴第一個Saga參與者，也就是子事務，去執行本地事務。事務完成之后Saga的會按照執行順序調用Saga的下一個參與的子事務。這個過程會一直持續到Saga事務執行完畢。

如果在執行子事務的過程中遇到子事務對應的本地事務失敗，則Saga會按照相反的順序執行補償事務。通常來說我們把這種Saga執行事務的順序稱為個Saga的協調邏輯。這種協調邏輯有兩種模式，編排(Choreography)和控制(Orchestration)分別如下：

編排(Choreography)：參與者(子事務)之間的調用、分配、決策和排序，通過交換事件進行進行。是一種去中心化的模式，參與者之間通過消息機制進行溝通，通過監聽器的方式監聽其他參與者發出的消息，從而執行后續的邏輯處理。由于沒有中間協調點，靠參與靠自己進行相互協調。

控制(Orchestration)：Saga提供一個控制類，其方便參與者之前的協調工作。事務執行的命令從控制類發起，按照邏輯順序請求Saga的參與者，從參與者那里接受到反饋以后，控制類在發起向其他參與者的調用。所有Saga的參與者都圍繞這個控制類進行溝通和協調工作。

下面通過一個例子來介紹這兩種協調模式，假設有一個下單的業務，從訂單服務的創建訂單操作發起，會依次調用支付服務中的支付訂單，庫存服務中的扣減庫存以及發貨服務中的發貨操作，最終如果所有參與者(服務)中的操作(子事務)完成的話，整個下單事務就算完成。

編排(Choreography)，由于沒有中心的控制類參與參與者操作之間的協調工作，因此通過消息發送的方式進行協調。

如圖3所示：

圖3 編排模式-事務執行成功

1. “訂單服務”中執行“創建訂單”操作，此時會發送一個“創建訂單消息”到隊列中。

2. “支付服務”監聽到隊列中的這個訂單消息，調用“支付訂單”的操作，同時也發送“只服務消息”到隊列中。

3. “庫存服務”在監聽到“支付消息”之后會進行“扣減庫存”的處理，并且發送“扣減庫存消息”等待下一個消費者接受。

4.  “發貨服務”作為整個事務的最后一個子事務，在接到“扣減庫存消息”以后會執行發貨的子事務，完成事務以后會給“訂單服務”發送“發貨消息”，訂單服務在接受到消息以后完成整個事務閉環，并且提交。

上面說的是事務執行成功的情況，如果事務執行失敗那應該如何處理?

如圖4所示：

圖4 編排模式-事務執行失敗

1. 假設在執行“發貨”時子事務失敗了，會發送“發貨失敗消息”。

2. 庫存服務在接受到“發貨失敗消息”之后會執行“回滾庫存”的操作，該操作將原來扣減的庫存加回去，同時發送“扣減失敗消息”。

3.  “支付服務”在接受到“扣減失敗消息”之后會執行“回滾支付”，進行退款的操作，同時發送“支付失敗消息”。訂單服務在接受到該消息以后將下單事務標記為失敗。

從上面的描述可以看出編排的好處：

簡單：每個子事務進行操作時只用發布事件消息，其他子事務監聽處理。

松耦合：參與者(服務)之間通過訂閱事件進行溝通，組合會更加靈活。

當然也有一些缺點：

理解困難：沒有對業務流程進行完整的描述，要了解整個事務的執行過程需要通過閱讀代碼完成。增加開發人員理解和維護代碼的難度。

存在服務的循環依賴：由于通過消息和事件進行溝通，參與者之間會存在循環依賴的情況。也就是A服務調用B服務，B服務又調用A服務的情況。這也增加了架構設計的復雜度，在設計初期需要認真考慮。

緊耦合風險：每個參與者執行的方法都依賴于上一步參與者發出的消息，但是上一步的參與者的所有消息都需要被訂閱，才能了解參與者的真實狀態，無形中增加了兩個服務的耦合度。

控制(Orchestration)，其核心是定義一個控制類，它會告訴參與者(服務)應該執行哪些操作(子事務)。  Saga控制類通過命令以及異步回復的方式與參與者進行交互。

如圖5所示：

圖5 控制模式-成功

1. 訂單服務執行下單事務時，向Saga協調器發送請求命令，Saga協調器接受到命令以后按照子事務執行的順序調用服務中的方法。

2. 最開始執行“支付訂單”的操作，調用“支付服務”中的“支付訂單”操作，并且通過虛線的部分返回執行結果“支付完成”。

3. 接下來，執行“庫存服務”中的“扣減庫存”方法，同樣通過虛線部分返回扣減完成的消息給“請求反饋“模塊。

4. 緊接著就是執行“發貨“命令，調用”發貨服務“中的”發貨“方法，并且返回”發貨完成“的響應。

5. 最后，三個子事務都執行完畢以后，返回訂單服務，完成整個分布式事務。

介紹完成成功完成事務之后，再來看看出現異常的情況。

如圖6所示：

圖6 控制模式-失敗

1. 在執行“發貨”命令時發現“發貨失敗”，于是“發貨服務”反饋給Saga協調器。

2. 此時協調器調用“庫存服務”中的“回滾庫存”操作，將扣減的庫存恢復。

3. 然后調用“支付服務”中的“回滾支付”完成支付退款的工作。

4. 最后，通知訂單服務事務處理失敗。

需要指出的是控制模式也是基于事件驅動的，與編排模式一樣會發送消息通知參與者執行命令，上面兩個圖中命令的執行和調用也是通過消息的方式進行。

控制器設計的優點：

避免循環依賴：在編排模式中存在參與者之間的循環調用，而中心控制類的方式可以避免這種情況的發生。

降低復雜性：所有事務交給控制器完成，它負責命令的執行和回復的處理，參與者只需要完成自身的任務，不用考慮處理消息的方式，降低參與者接入的復雜性。

容易測試：測試工作集中在集中控制類上，其他服務單獨測試功能即可。

容易擴展：如果事務需要添加新步驟，只需修改控制類，保持事務復雜性保持線性，回滾更容易管理。

當然這種方法也存在缺點：

依賴控制器：控制器中集中太多邏輯的風險。

增加管理難度：這種模式除了管理各個業務服務以外，還需要額外管理控制類服務，無形中增加了管理的難度和復雜度。而且存在單點風險，一旦控制器出現問題，整個業務就處于癱瘓中。

總結 

這里對Saga進行一個總結，首先Saga是針對分布式長活事務的解決方案，針對事務長、多、復雜的情況，特別是服務由多個公司開發具有不可控性，可以使用Saga模式進行分布式事務的處理。Saga在處理事務一致性方面采取了向前恢復和向后恢復策略，前者通過不斷重試的方式保證事務完成，而后者通過子事務的補償事務，逐一回滾的方式讓事務標記失敗。在分布式協調方面，Saga采用了兩種模式：編排和控制。前者讓參與者(服務)之間通過消息進行溝通，根據事件出發事務的執行流程，是一種去中心化的模式。后者通過中心控制類，處理事務的執行和回滾步驟，統一調用服務和接受服務的反饋。

“Saga實現分布式事務的內容有有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！