一、Seata 簡介

Seata 是阿里巴巴2019年開源的分佈式事務解決方案，致力於在微服務架構下提供高性能和簡單易用的分佈式事務服務。在 Seata 開源之前，Seata 對應的內部版本在阿里內部一直扮演着分佈式一致性中間件的角色，幫助阿里度過歷年的雙11，對各業務進行了有力的支撐。經過多年沉澱與積累，2019.1 Seata 正式宣佈對外開源。目前 Seata 1.0 已經 GA。

項目地址：https://github.com/seata/seata/

二、分佈式事務場景

在介紹分佈式事務下，下面我們先來了解一個常見應用場景，這個場景(類似慕課網購買付費課程)也是我後面要講的分佈式事務的解決方案的案例：

用戶支付完成會將支付狀態及訂單狀態保存在訂單數據庫中，由訂單服務去維護訂單數據庫。而學生選課信息在學習中心數據庫，由學習服務去維護學習中心數據庫的信息。下圖是系統結構圖：

如何實現兩個分佈式服務（訂單服務、學習服務）共同完成一件事即訂單支付成功自動添加學生選課的需求，這裏的關鍵是如何保證兩個分佈式服務的事務的一致性。

嘗試解決上邊的需求，在訂單服務中遠程調用選課接口，僞代碼如下：

下面我們分析下這種解決方案的問題

1.更新支付表狀態爲本地數據庫操作。
2.遠程調用選課接口爲網絡遠程調用請求
3.爲保存事務上邊兩步操作由spring控制事務，當遇到Exception異常則回滾本地數據庫操作。

問題如下：

1、如果更新支付表失敗則拋出異常，不再執行遠程調用，此設想沒有問題。
2、如果更新支付表成功，網絡遠程調用超時會拉長本地數據庫事務時間，影響數據庫性能。（遠程調用非常耗時的哦）
3、如果更新支付表成功，遠程調用添加選課成功（選課數據庫commit成功），最後更新支付表commit失敗，此時出現操作不一致。

上面的問題就涉及到了分佈式事務的控制

三、什麼是分佈式事務

1、什麼是分佈式系統

部署在不同結點上的系統通過網絡交互來完成協同工作的系統，比如：充值加積分的業務，用戶在充值系統向自己的賬戶充錢，在積分系統中自己積分相應的增加。充值系統和積分系統是兩個不同的系統，一次充值加積分的業務就需要這兩個系統協同工作來完成。

2、什麼是事務

事務是指由一組操作組成的一個工作單元，這個工作單元具有原子性（atomicity）、一致性（consistency）、隔離性（isolation）和持久性（durability）。

原子性：執行單元中的操作要麼全部執行成功，要麼全部失敗。如果有一部分成功一部分失敗那麼成功的操作要全部回滾到執行前的狀態。
一致性：執行一次事務會使用數據從一個正確的狀態轉換到另一個正確的狀態，執行前後數據都是完整的。
隔離性：在該事務執行的過程中，任何數據的改變只存在於該事務之中，對外界沒有影響，事務與事務之間是完全的隔離的。只有事務提交後其它事務纔可以查詢到最新的數據。
持久性：事務完成後對數據的改變會永久性的存儲起來，即使發生斷電宕機數據依然在。

3、什麼是本地事務

本地事務就是用關係數據庫來控制事務，關係數據庫通常都具有ACID特性，傳統的單體應用通常會將數據全部存儲在一個數據庫中，會藉助關係數據庫來完成事務控制。

4、什麼是分佈式事務

在分佈式系統中一次操作由多個系統協同完成，這種一次事務操作涉及多個系統通過網絡協同完成的過程稱爲分佈式事務。這裏強調的是多個系統通過網絡協同完成一個事務的過程，並不強調多個系統訪問了不同的數據庫，即使多個系統訪問的是同一個數據庫也是分佈式事務。另外一種分佈式事務的表現是，一個應用程序使用了多個數據源連接了不同的數據庫，當一次事務需要操作多個數據源，此時也屬於分佈式事務，當系統作了數據庫拆分後會出現此種情況。

四、分佈式事務裏的理論

1、CAP理論

1.1 CAP理論介紹

CAP理論是：分佈式系統在設計時只能在一致性(Consistency)、可用性(Availability)、分區容忍性(Partition Tolerance)中滿足兩種，無法兼顧三種。

一致性(Consistency)：服務A、B、C三個結點都存儲了用戶數據，三個結點的數據需要保持同一時刻數據一致性。
可用性(Availability)：服務A、B、C三個結點，其中一個結點宕機不影響整個集羣對外提供服務，如果只有服務A結點，當服務A宕機整個系統將無法提供服務，增加服務B、C是爲了保證系統的可用性。
分區容忍性(Partition Tolerance)：分區容忍性就是允許系統通過網絡協同工作，分區容忍性要解決由於網絡分區導致數據的不完整及無法訪問等問題。

1.2 分佈式系統能否兼顧C、A、P？

在保證分區容忍性的前提下一致性和可用性無法兼顧，如果要提高系統的可用性就要增加多個結點，如果要保證數據的一致性就要實現每個結點的數據一致，結點越多可用性越好，但是數據一致性越差。所以，在進行分佈式系統設計時，同時滿足“一致性”、“可用性”和“分區容忍性”三者是幾乎不可能的

1.3 CAP有哪些組合方式？

1、CA：放棄分區容忍性，加強一致性和可用性，關係數據庫按照CA進行設計。
2、AP：放棄一致性，加強可用性和分區容忍性，追求最終一致性，很多NoSQL數據庫按照AP進行設計。
說明：這裏放棄一致性是指放棄強一致性，強一致性就是寫入成功立刻要查詢出最新數據。追求最終一致性是指允許暫時的數據不一致，只要最終在用戶接受的時間內數據一致即可
3、CP：放棄可用性，加強一致性和分區容忍性，一些強一致性要求的系統按CP進行設計，比如跨行轉賬，一次轉賬請求要等待雙方銀行系統都完成整個事務纔算完成。

2、BASE理論

BASE理論是對CAP中的一致性和可用性進行一個權衡的結果，理論的核心思想就是：我們無法做到強一致，但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性。

Basically Available（基本可用）
Soft state（軟狀態）
Eventually consistent（最終一致性）

五、分佈式事務的解決方案

1、兩階段提交協議（2PC）

1）第一階段：準備階段（prepare）

協調者通知參與者準備提交訂單，參與者開始投票。

協調者完成準備工作向協調者回應Yes。

2）第二階段：提交(commit)/回滾(rollback)階段

協調者根據參與者的投票結果發起最終的提交指令。

如果有參與者沒有準備好則發起回滾指令。

2、事務補償（TCC）

TCC事務補償是基於2PC實現的業務層事務控制方案，它是Try、Confirm和Cancel三個單詞的首字母，含義如下：

1）Try 檢查及預留業務資源完成提交事務前的檢查，並預留好資源。

2）Confirm 確定執行業務操作

對try階段預留的資源正式執行。

3）Cancel 取消執行業務操作

對try階段預留的資源釋放。

3、消息隊列實現最終一致

本方案是將分佈式事務拆分成多個本地事務來完成，並且由消息隊列異步協調完成。

六、Seata分佈式事務解決方案

Seata有3個基本組成部分：

事務協調器（TC）：維護全局事務和分支事務的狀態，驅動全局提交或回滾。
事務管理器TM：定義全局事務的範圍：開始全局事務，提交或回滾全局事務。
資源管理器（RM）：管理正在處理的分支事務的資源，與TC對話以註冊分支事務並報告分支事務的狀態，並驅動分支事務的提交或回滾。

Seata管理的分佈式事務的典型生命週期：

TM要求TC開始一項新的全局事務。TC生成代表全局事務的XID。
XID通過微服務的調用鏈傳播。
RM將本地事務註冊爲XID到TC的相應全局事務的分支。
TM要求TC提交或回退相應的XID全局事務。
TC驅動XID的相應全局事務下的所有分支事務以完成分支提交或回滾。

參考更多Seata原理：http://seata.io/zh-cn/docs/overview/what-is-seata.html

分佈式事務解決方案Seata