出席分佈式事務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 的一個擴展

1. BA 基本可用：分佈式系統在出現故障時，容許損失部分可用功能，保證核心功能可用。
2. S 軟狀態：容許系統中存在中間狀態，這個狀態不影響系統可用性，這裏指的是 CAP 中的不一致。
3. E 最終一致：最終一致是指通過一段時間後，全部節點數據都將會達到一致。

BASE 解決了 CAP 中理論沒有網絡延遲，在 BASE 中用軟狀態和最終一致，保證了延遲後的一致性。

BASE 和 ACID 是相反的，它徹底不一樣於 ACID 的強一致性模型，而是經過犧牲強一致性來得到可用性，並容許數據在一段時間內是不一致的，但最終達到一致狀態。

對於大部分的分佈式應用而言，只要數據在規定的時間內達到最終一致性便可。

咱們能夠把符合傳統的 ACID 叫作剛性事務，把知足 BASE 理論的最終一致性事務叫作柔性事務。

具體到分佈式事務的實現上，業界主要採用了 XA 協議的強一致規範以及柔性事務的最終一致規範。

What's Seata

Seata 是一款開源的分佈式事務解決方案，提供高性能和簡單易用的分佈式事務服務。

Github: https://github.com/seata/seata

官網: https://seata.io/

1. 支持各微服務框架: 目前已支持Dubbo、Spring Cloud、Sofa-RPC、Motan和gRPC等RPC框架，其餘框架持續集成中。
2. AT自動補償模式: 提供無侵入自動補償的事務模式，目前已支持MySQL、Oracle的自動補償模式，PostgreSQL、H2開發中。
3. TCC模式: 支持用戶使用TCC靈活擴展事務。
4. Saga模式: 提供長事務和服務編排解決方案。
5. 高可用: 支持基於數據庫存儲的集羣模式，水平擴展能力強。
6. 高擴展性: 支持各種配置中心、註冊中心、序列化、存儲、協議序列化、負載均衡等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

核心價值

1. 低成本：編程模型 不變，輕依賴 不須要爲分佈式事務場景作特定設計。
2. 高性能：一階段提交，不阻塞；鏈接釋放，保證整個系統的吞吐。
3. 高可用：極端的異常狀況下，能夠暫時 跳過異常事務，保證系統可用。

能力邊界

業務無侵入	業務侵入
AT	TCC
XA	Saga

TCC模式

TCC 模型是把鎖的粒度徹底交給業務處理，它須要每一個子事務業務都實現Try-Confirm / Cancel 接口。

TCC 模式本質也是 2PC ，只是 TCC 在應用層控制。

• Try:

  • 嘗試執行業務
  • 完成全部業務檢查（一致性）
  • 預留必須業務資源（準隔離性）

• Confirm:

  • 確認執行業務；
  • 真正執行業務，不做任何業務檢查
  • 只使用Try階段預留的業務資源
  • Confirm 操做知足冪等性

• Cancel:

  • 取消執行業務
  • 釋放Try階段預留的業務資源
  • Cancel操做知足冪等性

這三個階段，都會按本地事務的方式執行。不一樣於 XA的prepare ，TCC 無需將 XA 的投票期間的全部資源掛起，所以極大的提升了吞吐量。

Saga模式

基礎原理

1. 核心思想是將長事務拆分爲多個本地短事務，由 Saga 事務協調器協調，若是正常結束那就正常完成，若是某個步驟失敗，則根據相反順序一次調用補償操做
2. Hector & Kenneth 發表論⽂ Sagas （1987）

使用場景

• 業務流程長，業務流程多

• 參與者包含其餘公司或遺留系統服務，沒法提供TCC模式要求的三個接口

• 典型業務系統: 如金融網絡(與外部機構對接)、互聯網微貸、渠道整合、分佈式架構下服務集成等業務系統

• 銀行業金融機構使用普遍

優點

• 一階段提交本地事務、無鎖、高性能。
• 參與者可異步執行、高吞吐
• 補償服務易於實現

缺點

• 不保證隔離

參會照片

會議易拉寶，地點放在杭州青年衆創空間

會議內部圖片

seata貼紙

原文出處：https://www.cnblogs.com/sanshengshui/p/12094894.html