出席分散式事務Seata 1.0.0 GA典禮
前言
圖中那個紅衣服的就是本人
什麼是分散式事務
分散式事務就是指事務的參與者、支援事務的伺服器、資源伺服器以及事務管理器分別位於不同的分散式系統的不同節點之上。
簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分佈在不同的伺服器上，且屬於不同的應用，分散式事務需要保證這些小操作要麼全部成功，要麼全部失敗。
本質上來說，分散式事務就是為了保證不同資料庫的資料一致性。
分散式事務的基礎
資料庫的 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
官網: https://seata.io/
- 支援各微服務框架: 目前已支援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貼紙