什么是分布式事務
分布式事務就是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不同的分布式系統的不同節點之上。
簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務器上，且屬於不同的應用，分布式事務需要保證這些小操作要么全部成功，要么全部失敗。
本質上來說，分布式事務就是為了保證不同數據庫的數據一致性。
分布式事務的基礎
數據庫的 ACID 滿足了數據庫本地事務的基礎，但是它無法滿足分布式事務，這個時候衍生了 CAP 和 BASE 兩個經典理論。
CAP理論
-
C (一致性)：在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
-
A (可用性)：在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
-
P (分區容錯性)：以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在 C 和 A 之間做出選擇。
Eureka 主從同步是 AP 系統
Zookeeper 是 CP 系統
BASE理論
BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性) 三個短語的縮寫。是對 CAP 中AP 的一個擴展
- BA 基本可用：分布式系統在出現故障時，允許損失部分可用功能，保證核心功能可用。
- S 軟狀態：允許系統中存在中間狀態，這個狀態不影響系統可用性，這里指的是 CAP 中的不一致。
- E 最終一致：最終一致是指經過一段時間后，所有節點數據都將會達到一致。
BASE 解決了 CAP 中理論沒有網絡延遲，在 BASE 中用軟狀態和最終一致，保證了延遲后的一致性。
BASE 和 ACID 是相反的，它完全不同於 ACID 的強一致性模型，而是通過犧牲強一致性來獲得可用性，並允許數據在一段時間內是不一致的，但最終達到一致狀態。
對於大部分的分布式應用而言，只要數據在規定的時間內達到最終一致性即可。
我們可以把符合傳統的 ACID 叫做剛性事務，把滿足 BASE 理論的最終一致性事務叫做柔性事務。
具體到分布式事務的實現上，業界主要采用了 XA 協議的強一致規范以及柔性事務的最終一致規范。
What's Seata
Seata 是一款開源的分布式事務解決方案，提供高性能和簡單易用的分布式事務服務。
Github: https://github.com/seata/seata
- 支持各微服務框架: 目前已支持Dubbo、Spring Cloud、Sofa-RPC、Motan和gRPC等RPC框架，其他框架持續集成中。
- AT自動補償模式: 提供無侵入自動補償的事務模式，目前已支持MySQL、Oracle的自動補償模式，PostgreSQL、H2開發中。
- TCC模式: 支持用戶使用TCC靈活擴展事務。
- Saga模式: 提供長事務和服務編排解決方案。
- 高可用: 支持基於數據庫存儲的集群模式，水平擴展能力強。
- 高擴展性: 支持各類配置中心、注冊中心、序列化、存儲、協議序列化、負載均衡等SPI擴展。
AT自動補償模式
XA 是 X/Open CAE Specification (Distributed Transaction Processing)模型，它定義的 TM（Transaction Manager）與 RM（Resource Manager）之間進行通信的接口。
Java中 的 javax.transaction.xa.XAResource 定義了 XA 接口，它依賴數據庫廠商對 jdbc-driver 的具體實現。
mysql-connector-java-5.1.30的實現可參com.mysql.jdbc.jdbc2.optional.MysqlXAConnection類。
在 XA 規范中，數據庫充當 RM 角色，應用需要充當 TM 的角色，即生成全局的 txId ，調用 XAResource 接口，把多個本地事務協調為全局統一的分布式事務。
目前 XA 有兩種實現：
- 基於一階段提交( 1PC ) 的弱 XA 。
- 基於二階段提交( 2PC ) 的強 XA 。
AT自動補償模式就是基於一階段提交的弱XA
核心價值
- 低成本：編程模型 不變，輕依賴 不需要為分布式事務場景做特定設計。
- 高性能：一階段提交，不阻塞；連接釋放，保證整個系統的吞吐。
- 高可用：極端的異常情況下，可以暫時 跳過異常事務，保證系統可用。
能力邊界
| 業務無侵入 | 業務侵入 |
|---|---|
| AT | TCC |
| XA | Saga |
TCC模式
TCC 模型是把鎖的粒度完全交給業務處理，它需要每個子事務業務都實現Try-Confirm / Cancel 接口。
TCC 模式本質也是 2PC ，只是 TCC 在應用層控制。
- Try:
- 嘗試執行業務
- 完成所有業務檢查（一致性）
- 預留必須業務資源（准隔離性）
- Confirm:
- 確認執行業務；
- 真正執行業務，不作任何業務檢查
- 只使用Try階段預留的業務資源
- Confirm 操作滿足冪等性
- Cancel:
- 取消執行業務
- 釋放Try階段預留的業務資源
- Cancel操作滿足冪等性
這三個階段，都會按本地事務的方式執行。不同於 XA的prepare ，TCC 無需將 XA 的投票期間的所有資源掛起，因此極大的提高了吞吐量。
Saga模式
基礎原理
- 核心思想是將長事務拆分為多個本地短事務，由 Saga 事務協調器協調，如果正常結束那就正常完成，如果某個步驟失敗，則根據相反順序一次調用補償操作
- Hector & Kenneth 發表論⽂ Sagas （1987）
使用場景
-
業務流程長，業務流程多
-
參與者包含其他公司或遺留系統服務，無法提供TCC模式要求的三個接口
-
典型業務系統: 如金融網絡(與外部機構對接)、互聯網微貸、渠道整合、分布式架構下服務集成等業務系統
-
銀行業金融機構使用廣泛
優勢
- 一階段提交本地事務、無鎖、高性能。
- 參與者可異步執行、高吞吐
- 補償服務易於實現
缺點
- 不保證隔離
參會照片
會議易拉寶，地點放在杭州青年眾創空間
會議內部圖片
seata貼紙