開篇
随着微服務架構的興起，越來越多的公司會在實際場景中遇到分布式事務的問題。特别是在金融應用場景，幾個跨程序的應用共同完成一個任務，就更離不開分布式事務的參與。而對于分布式事務而言，2PC、TCC也是經常被提到了，不過在面對長業務流程，并且很難進行TCC改造的場景，會選擇使用Saga分布式事務。今天會給大家介紹Saga實作分布式事務的内容：
- Saga的分布式解決方案
- Saga處理事務一緻性
- Saga分布式事務協調
随着網際網路的快速發展，原來的單體應用已經很難支撐大流量高并發的請求了，是以軟體系統由原來的單體應用逐漸向分布式過度，如圖1所示，左邊的Web App 包含了UI和服務的子產品，在轉變以後會對應右邊的微服務架構，服務之間存在關聯地互相調用。
圖1 單體到分布式的系統架構過渡
在進行分布式部署之後，會存在多個服務共同完成一個事務操作，并且這些服務彼此都存在于不同的伺服器或者網絡環境，服務之間需要通過網絡遠端協作完成事務稱之為分布式事務。例如：銀行轉賬業務、下單扣件庫存等。
在分布式事務場景下，如果對資料有強一緻性要求，會在業務層上才去“兩階段送出”（2PC）的方案。如果保證最終一緻性的話可以采取TCC （Try Confirm Cancel）模式。雖然TCC保證最終一緻性的模式被業内廣泛使用，但是對于某些分布式事務場景，流程多、流程長、還可能要調用其它公司的服務。特别是對于不可控的服務（其他公司的服務），這些服務無法遵循 TCC 開發模式，導緻TCC模式的開發成本增高。展現在具體場景中，以金融核心的業務為代表（管道層、産品層、內建層），其特點是：流程多、流程長、調用不可控服務。同時也是應為流程長，事務邊界太長，加鎖時間長，使用TCC模式會影響并發性能。
鑒于此類業務場景的分布式事務處理，提出了Saga分布式處理模式。Saga是一種“長事務的解決方案”，更适合于“業務流程長、業務流程多”的場景。特别是針對參與事務的服務是遺留系統服務，此類服務無法提供TCC模式下的三個接口，就可以采用Saga模式。
其适用于的業務業務場景有，金融機構對接系統（需要對接外部系統）、管道整合（流程長）、分布式架構服務等。其優勢是一階段送出本地事務，無鎖，高性能；參與者可異步執行，高吞吐；補償服務易于實作，因為一個更新操作的反向操作是比較容易了解的；當然其也存在缺點，就是不保證隔離性。
1987年普林斯頓大學的Hector Garcia-Molina和Kenneth Salem發表了一篇Paper Sagas，講述的是如何處理long lived transaction（長活事務）。Saga是一個長活事務可被分解成可以交錯運作的子事務集合。其中每個子事務都是一個保持資料庫一緻性的真實事務。
在這位老兄的論文中提到，每個Saga由一系列sub-transactionTi
組成。每個Ti都有對應的補償動作Ci，補償動作用于撤銷Ti造成的結果。這裡可以了解為，針對每一個分布式事務的每個執行操作或者是步驟都是一個 Ti，例如扣減庫存是T1、建立訂單是T2、支付服務是T3。那麼針對每個Ti都對應一個補償動作Ci，例如回複庫存C1、訂單復原C2、支付復原C3。
Saga事務有兩種恢複政策：
向前恢複（forward recovery），也就是“勇往直前”。對于執行不通過的事務，會嘗試重試事務，這裡有一個假設就是每個子事務最終都會成功。這種方式适用于必須要成功的場景，如圖2 所示，上面的圖例，子事務按照從左到右的順序執行，T1執行完畢以後T2 執行，然後是T3、T4、T5。事務恢複的順序也是按照：T1、T2、T3、T4、T5的方向進行，如果在執行T1的時候失敗了就重試T1，以此類推在哪個子事務執行時失敗了就執行哪個事務。是以叫做“勇往直前”。
向後恢複（backward recovery），在執行事務失敗時，補償所有已完成的事務，是“一退到底”的方式。如圖2所示，下面的圖例，子事務依舊從左往右執行，在執行到事務T3的時候，該事務執行失敗了，于是按照紅線的方向開始執行補償事務，先執行C3、然後是C2和C1，直到T0、T1、T2的補償事務C1、C2、C3都執行完畢。也就是復原整個Saga的執行結果。
圖2 Saga事務執行的政策
上面介紹了Saga的概念和事務恢複方式，每個事務存在多個子事務，每個子事務都有一個補償事務，其在事務復原的時候使用。由于子事務對應的操作在分布式的系統架構中會部署在不同的服務中，這些子事務為了完成共同的事務需要進行協同。實際上在啟動一個Saga事務時，協調邏輯會告訴第一個Saga參與者，也就是子事務，去執行本地事務。事務完成之後Saga的會按照執行順序調用Saga的下一個參與的子事務。這個過程會一直持續到Saga事務執行完畢。如果在執行子事務的過程中遇到子事務對應的本地事務失敗，則Saga會按照相反的順序執行補償事務。通常來說我們把這種Saga執行事務的順序稱為個Saga的協調邏輯。這種協調邏輯有兩種模式，編排（Choreography）和控制（Orchestration）分别如下：
編排（Choreography）：參與者（子事務）之間的調用、配置設定、決策和排序，通過交換事件進行進行。是一種去中心化的模式，參與者之間通過消息機制進行溝通，通過監聽器的方式監聽其他參與者發出的消息，進而執行後續的邏輯處理。由于沒有中間協調點，靠參與靠自己進行互相協調。
控制（Orchestration）：Saga提供一個控制類，其友善參與者之前的協調工作。事務執行的指令從控制類發起，按照邏輯順序請求Saga的參與者，從參與者那裡接受到回報以後，控制類在發起向其他參與者的調用。所有Saga的參與者都圍繞這個控制類進行溝通和協調工作。
下面通過一個例子來介紹這兩種協調模式，假設有一個下單的業務，從訂單服務的建立訂單操作發起，會依次調用支付服務中的支付訂單，庫存服務中的扣減庫存以及發貨服務中的發貨操作，最終如果所有參與者（服務）中的操作（子事務）完成的話，整個下單事務就算完成。
編排（Choreography），由于沒有中心的控制類參與參與者操作之間的協調工作，是以通過消息發送的方式進行協調。如圖3所示，
1. “訂單服務”中執行“建立訂單”操作，此時會發送一個“建立訂單消息”到隊列中。
2. “支付服務”監聽到隊列中的這個訂單消息，調用“支付訂單”的操作，同時也發送“隻服務消息”到隊列中。
3. “庫存服務”在監聽到“支付消息”之後會進行“扣減庫存”的處理，并且發送“扣減庫存消息”等待下一個消費者接受。
4. “發貨服務”作為整個事務的最後一個子事務，在接到“扣減庫存消息”以後會執行發貨的子事務，完成事務以後會給“訂單服務”發送“發貨消息”，訂單服務在接受到消息以後完成整個事務閉環，并且送出。
圖3 編排模式-事務執行成功
上面說的是事務執行成功的情況，如果事務執行失敗那應該如何處理？如圖4所示，
1. 假設在執行“發貨”時子事務失敗了，會發送“發貨失敗消息”。
2. 庫存服務在接受到“發貨失敗消息”之後會執行“復原庫存”的操作，該操作将原來扣減的庫存加回去，同時發送“扣減失敗消息”。
3. “支付服務”在接受到“扣減失敗消息”之後會執行“復原支付”，進行退款的操作，同時發送“支付失敗消息”。訂單服務在接受到該消息以後将下單事務标記為失敗。
圖4 編排模式-事務執行失敗
從上面的描述可以看出編排的好處：
簡單：每個子事務進行操作時隻用釋出事件消息，其他子事務監聽處理。
松耦合：參與者（服務）之間通過訂閱事件進行溝通，組合會更加靈活。
當然也有一些缺點：
了解困難：沒有對業務流程進行完整的描述，要了解整個事務的執行過程需要通過閱讀代碼完成。增加開發人員了解和維護代碼的難度。
存在服務的循環依賴：由于通過消息和事件進行溝通，參與者之間會存在循環依賴的情況。也就是A服務調用B服務，B服務又調用A服務的情況。這也增加了架構設計的複雜度，在設計初期需要認真考慮。
緊耦合風險：每個參與者執行的方法都依賴于上一步參與者發出的消息，但是上一步的參與者的所有消息都需要被訂閱，才能了解參與者的真實狀态，無形中增加了兩個服務的耦合度。
控制（Orchestration），其核心是定義一個控制類，它會告訴參與者（服務）應該執行哪些操作（子事務）。 Saga控制類通過指令以及異步回複的方式與參與者進行互動。如圖5所示，
1. 訂單服務執行下單事務時，向Saga協調器發送請求指令，Saga協調器接受到指令以後按照子事務執行的順序調用服務中的方法。
2. 最開始執行“支付訂單”的操作，調用“支付服務”中的“支付訂單”操作，并且通過虛線的部分傳回執行結果“支付完成”。
3. 接下來，執行“庫存服務”中的“扣減庫存”方法，同樣通過虛線部分傳回扣減完成的消息給“請求回報“子產品。
4. 緊接着就是執行“發貨“指令，調用”發貨服務“中的”發貨“方法，并且傳回”發貨完成“的響應。
5. 最後，三個子事務都執行完畢以後，傳回訂單服務，完成整個分布式事務。
圖5 控制模式-成功
介紹完成成功完成事務之後，再來看看出現異常的情況，如圖6所示，
1. 在執行“發貨”指令時發現“發貨失敗”，于是“發貨服務”回報給Saga協調器。
2. 此時協調器調用“庫存服務”中的“復原庫存”操作，将扣減的庫存恢複。
3. 然後調用“支付服務”中的“復原支付”完成支付退款的工作。
4. 最後，通知訂單服務事務處理失敗。
圖6 控制模式-失敗
需要指出的是控制模式也是基于事件驅動的，與編排模式一樣會發送消息通知參與者執行指令，上面兩個圖中指令的執行和調用也是通過消息的方式進行。
控制器設計的優點：
避免循環依賴：在編排模式中存在參與者之間的循環調用，而中心控制類的方式可以避免這種情況的發生。
降低複雜性：所有事務交給控制器完成，它負責指令的執行和回複的處理，參與者隻需要完成自身的任務，不用考慮處理消息的方式，降低參與者接入的複雜性。
容易測試：測試工作集中在集中控制類上，其他服務單獨測試功能即可。
容易擴充：如果事務需要添加新步驟，隻需修改控制類，保持事務複雜性保持線性，復原更容易管理。
當然這種方法也存在缺點：
依賴控制器：控制器中集中太多邏輯的風險。
增加管理難度：這種模式除了管理各個業務服務以外，還需要額外管理控制類服務，無形中增加了管理的難度和複雜度。而且存在單點風險，一旦控制器出現問題，整個業務就處于癱瘓中。
總結
這裡對Saga進行一個總結，首先Saga是針對分布式長活事務的解決方案，針對事務長、多、複雜的情況，特别是服務由多個公司開發具有不可控性，可以使用Saga模式進行分布式事務的處理。Saga在處理事務一緻性方面采取了向前恢複和向後恢複政策，前者通過不斷重試的方式保證事務完成，而後者通過子事務的補償事務，逐一復原的方式讓事務标記失敗。在分布式協調方面，Saga采用了兩種模式：編排和控制。前者讓參與者（服務）之間通過消息進行溝通，根據事件出發事務的執行流程，是一種去中心化的模式。後者通過中心控制類，處理事務的執行和復原步驟，統一調用服務和接受服務的回報。