一篇入門分布式事務

今天來聊聊分布式事務吧

• 我之前有篇文章寫過CAP以及BASE理論（文章鏈接），但對于分布式講的比較淺也比較模糊，隨著專案實踐應用以及碼齡的漸長，對分布式的理解又多了一點點點點點的認知，因此重寫一篇對分布式事務來記錄一下入門概念，
• 上篇文章（Kafka，RabbitMQ，RockedMQ真實應用開發大匯總1）設定了只可粉絲可見，收割了五十位粉絲，我對設定粉絲可見的文章的標準是：1.對實際生產開發有很大幫助 2.我自己也花了一段時間去學習理解的東西 3.能夠鍛煉編程思維 4.目前主流的技術堆疊和技術難點的文章
• 如果有任何問題，歡迎留言區或私信進行交流，
• 歡迎點贊，關注
• 本篇文章核心快速概覽
  • 1.本地事物與分布式事務
  • 2.分布式理論
  • 3.分布式事務解決方案概覽
  • 4.剛性，柔性事務（XA，TCC）
  • 5.主流分布式方案介紹（seata，事務訊息mq）

本地事務與分布式事務

• 事務指的就是一個操作單元，在這個操作單元中的所有操作最終要保持一致的行為，要么所有操作都成功，要么所有的操作都被撤銷
• 事務分兩種：
  • 一個是本地事務：本地事物其實可以認為是資料庫提供的事務機制
  • 一個是分布式事務

本地事務

• 相信大家對本地事務都不陌生，在單體開發中需要資料強一致性的時候或多或少都有用到過，目前最用的就是以注解的形式，進行事務標注，

    @Transactional(rollbackFor=Exception.class,propagation= Propagation.REQUIRED)
    public void test() {
    //資料庫操作
    }

• @Transactional()里的引數不做過多贅述，有興趣的小伙伴可以自行了解或復習，最常用的引數其實就是上面這個，在發生exception的時候進行回滾，事物創建機制為required，

分布式事務

• 那分布式事務又是怎么一回事？
• 先看一些定義
  • 指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位于不同的分布式系統的不同節點之上，
  • 簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務器上，且屬于不同的應用分布式事務需要保證這些小操作要么全部成功，要么全部失敗，
  • 本質上來說，分布式事務就是為了保證不同資料庫的資料一致性
• 我的一些理解：首先明確分布式事務是發生在多節點部署服務中的（SOA或微服務框架），目的是為了保證多節點的資料一致性，
  可能看完定義還有點蒙，上一個業務場景來看一下，
  （剛剛學著畫圖分析業務場景，比較丑，）
  
• 我們來設想一個業務場景，當用戶下單后，由訂單服務遠程呼叫商品服務的介面，這個時候，商品服務庫存扣減成功了，但是優惠券服務宕機
• 或者出錯了，優惠券卻沒有扣減成功，發生了資料不一致，
  或者是優惠券給用戶扣減掉了，但是商品服務出錯了，庫存沒有扣減成功，但是用戶的優惠券卻永遠的消失在了他的背包里，，，
• 我們原來的本地事務這個時候就失效了，本地事務只能保證自己的資料一致，而不能通知隔壁人家業務執行的非倉成功的服務進行回滾操作，

在講分布式事務之前還是得先引入兩個非常重要的理論，CAP和BASE

• 理論理論，是對人的思維想法進行指導，對實際業務開發起指導作用，

• CAP理論

CAP定理

• 指的是在一個分布式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（磁區容錯性），三者不可同時獲得

• 一致性（C）：所有節點都可以訪問到最新的資料

• 可用性（A）：每個請求都是可以得到回應的，不管請求是成功還是失敗

• 磁區容錯性（P）：除了全部整體網路故障，其他故障都不能導致整個系統不可用

• CAP理論就是說在分布式存盤系統中，最多只能實作上面的兩點，而由于當前的網路硬體肯定會出現延遲丟包等問題，所以磁區容忍性是我們必須需要實作的，所以我們只能在一致性和可用性之間進行權衡

• CA： 如果不要求P（不允許磁區），則C（強一致性）和A（可用性）是可以保證的，但放棄P的同時也就意味著放棄了系統的擴展性，也就是分布式節點受限，沒辦法部署子節點，這是違背分布式系統設計的初衷的

• CP: 如果不要求A（可用），每個請求都需要在服務器之間保持強一致，而P（磁區）會導致同步時間無限延長(也就是等待資料同步完才能正常訪問服務)，一旦發生網路故障或者訊息丟失等情況，就要犧牲用戶的體驗，等待所有資料全部一致了之后再讓用戶訪問系統

• AP：要高可用并允許磁區，則需放棄一致性，一旦磁區發生，節點之間可能會失去聯系，為了高可用，每個節點只能用本地資料提供服務，而這樣會導致全域資料的不一致性，

• 分布式系統中P,肯定要滿足，所以只能在CA中二選一
• 沒有最好的選擇，最好的選擇是根據業務場景來進行架構設計
• 如果要求一致性，則選擇zookeeper/Nacos，如金融行業 CP
• 如果要求可用性，則Eureka/Nacos，如電商系統 AP
• CP ： 適合支付、交易類，要求資料強一致性，寧可業務不可用，也不能出現臟資料
• AP: 互聯網業務，比如資訊流架構，不要求資料強一致，更想要服務可用

BASE理論

• 由來自 ebay 的架構師提出:CAP 中的一致性和可用性進行一個權衡的結果，核心思想就是：我們無法做到強一致，但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性

• Basically Available(基本可用)

  • 假設系統，出現了不可預知的故障，但還是能用, 可能會有性能或者功能上的影響

• Soft state（軟狀態）

  • 允許系統中的資料存在中間狀態，并認為該狀態不影響系統的整體可用性，即允許系統在多個不同節點的資料副本存在資料延時

• Eventually consistent（最終一致性）

  • 系統能夠保證在沒有其他新的更新操作的情況下，資料最終一定能夠達到一致的狀態，因此所有客戶端對系統的資料訪問最終都能夠獲取到最新的值，

• 關于資料一致性
  • 強一致：操作后的能立馬一致且可以訪問
  • 弱一致：容忍部分或者全部訪問不到
  • 最終一致：弱一致性經過多一段時間后，都一致且正常
  • 不難看出來，最終一致性在性能與業務方面得到了一個綜合，也是目前大多數分布式框架采用的思想，

分布式事務常見解決方案概覽

• 常見分布式事務解決方案

  • 2PC 和 3PC
    • 兩階段提交, 基于XA協議
  • TCC
    • Try、Confirm、Cancel
  • 事務訊息
    • 最大努力通知型

• 分布式事務分類

  • 剛性事務：遵循ACID
  • 柔性事務：遵循BASE理論

• 分布式事務框架

  • TX-LCN：支持2PC、TCC等多種模式
    • https://github.com/codingapi/tx-lcn
    • 更新慢（個人感覺處于停滯狀態）
  • Seata：支持 AT、TCC、SAGA 和 XA 多種模式
    • https://github.com/seata/seata
    • 背靠阿里，專門團隊推廣
    • 阿里云商業化產品GTS
      • https://www.aliyun.com/aliware/txc
  • RocketMq：自帶事務訊息解決分布式事務
    • https://github.com/apache/rocketmq

XA

• X/OpenDTP 事務模型
  是X/Open 這個組織定義的一套分布式事務的標準，也就是定義了規范和 API 介面，由各個廠商進行具體的實作
  DTP 是分布式事物處理(Distributed Transaction Processing)的簡稱

• XA協議
  A是由X/Open組織提出的分布式事務規范；
  XA規范主要定義了(全域)事務管理器?和(局 部)資源管理器(RM)之間的介面；
  主流的資料庫產品都實作了XA介面，是一個雙向的系統介面，在事務管理器以及多個資源管理器之間作為通信橋梁/

• JTA
  Java Transaction API,java根據XA規范提供的事務處理標準

• AP
  Application, 應用程式也就是業務層，微服務等

• RM
  Resource Manager，資源管理器，一般是資料庫，也可以是其他資源管理器，比如訊息佇列，檔案系統

• TM
  Transaction Manager ，事務管理器、事務協調者，負責接收來自用戶程式（AP）發起的 XA 事務指令，并調度和協調參與事務的所有 RM（資料庫），確保事務正確完成

• 在分布式系統中，每一個機器節點能夠明確知道自己在進行事務操作程序中的 結果是成功還是失敗，但無法直接獲取到其他分布式節點的操作結果
  當一個事務操作跨越多個分布式節點的時候，為了保持事務處理的 ACID 特性，
  需要引入一個“協調者”（TM）來統一調度所有分布式節點的執行邏輯，這些被調度的分布式節點被稱為 AP，
  TM 負責調度 AP 的行為，并最終決定這些 AP 是否要把事務真正進行提交到（RM）

XA協議規范-實作分布式事務的原理

• 一般習慣稱為 兩階段提交協議（The two-phase commit protocol，2PC）

• 是XA用于在全域事務中協調多個資源的機制，MySql5.5以上開始支持

• 準備階段：

  事務管理器給每個參與者都發送Prepared訊息，每個資料庫參與者在本地執行事務，并寫本地的Undo/Redo日志，此時事務沒有提交，

  • Undo日志是記錄修改前的資料，用于資料庫回滾
  • Redo日志是記錄修改后的資料，用于提交事務后寫入資料

• 提交階段：

  • 如果事務管理器收到了參與者的執行失敗或者超時訊息時，直接給每個參與者發送回滾（Rollback）訊息,否則發送提交（Commit）訊息;
  • 參與者根據事務管理器的指令執行【提交】或者【回滾】操作，并釋放事務處理程序中使用的鎖資源
  • 注意：必須在最后階段釋放鎖資源，

XA總結

• XA協議簡單，資料庫支持XA協議，開發使用成本比較低
• 對業務侵?很小，最?的優勢就是對使??透明
• 用戶可以像使?本地事務?樣使?基于 XA 協議的分布式事務，能夠嚴格保障事務 ACID 特性
• 事務執?程序中需要將所需資源全部鎖定，也就是俗稱的剛性事務
  • 剛性事務：遵循ACID
  • 柔性事務：遵循BASE理論
• 性能不理想，占用鎖資源比較多，高并發常見下無法滿足
• 商業付費資料庫支持好，mysql目前支持不是很完善
• 基于 XA 協議的 除了2PC，還有 3PC等
  • 三段提交（3PC）是二階段提交（2PC）的一種改進版本 ，為解決兩階段提交協議的阻塞問題
  • 采用超時機制，解決TM故障后RM的阻塞問題，但與此同時卻多了一次網路通信，性能上也不理想
• 2PC和3PC目前使用不是很多，只做簡單了解即可

TCC

• 什么是TCC柔性事務
  • 剛性事務：遵循ACID
  • 柔性事務：遵循BASE理論
  • TCC:
    • 將事務提交分為
      • Try：完成所有業務檢查( 一致性 ) ，預留必須業務資源( 準隔離性 )
      • Confirm ：對業務系統做確認提交，默認 Confirm階段不會出錯的 即只要Try成功，Confirm一定成功
      • Cancel : 業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放, 進行補償性
    • TCC 事務和 2PC 的類似，Try為第一階段，Confirm - Cancel為第二階段，它對事務的提交/回滾是通過執行一段 confirm/cancel 業務邏輯來實作，并且也并沒有全域事務來把控整個事務邏輯

• TCC的互動圖（圖片來源網上，沒有找到原出處，侵權必刪）
  
• 優點：
  • 它把事務運行程序分成 Try、Confirm/Cancel 兩個階段
  • 每個階段由業務代碼控制，這樣事務的鎖力度可以完全自由控制
  • 不存在資源阻塞的問題，每個方法都直接進行事務的提交
• 缺點
  • 在業務層撰寫代碼實作的兩階段提交，原本一個方法，現在卻需要三個方法來支持
  • 對業務的侵入性很強，不能很好的復用
• 注意：使用TCC時要注意Try - Confirm - Cancel 3個操作的冪等控制，由于網路原因或者重試操作都有可能導致這幾個操作的重復執行

簡介：講解分布式事務的解決方案之一事務訊息

• 事務訊息

  • 訊息佇列提供類似Open XA的分布式事務功能，通過訊息佇列事務訊息能達到分布式事務的最終一致

• 半事務訊息

  • 暫不能投遞的訊息，發送方已經成功地將訊息發送到了訊息佇列服務端，但是服務端未收到生產者對該訊息的二次確認，此時該訊息被標記成“暫不能投遞”狀態，處于該種狀態下的訊息即半事務訊息，

• 訊息回查

  • 由于網路閃斷、生產者應用重啟等原因，導致某條事務訊息的二次確認丟失，訊息佇列服務端通過掃描發現某條訊息長期處于“半事務訊息”時，需要主動向訊息生產者詢問該訊息的最終狀態（Commit或是Rollback），該詢問程序即訊息回查

• 互動圖（來源rocketmq官方檔案）
  

• 目前較為主流的MQ，比如ActiveMQ、RabbitMQ、Kafka、RocketMQ等，只有RocketMQ支持事務訊息

  • 如果其他佇列需要事務訊息，可以開發個訊息服務，自行實作半訊息和回查功能

• 好處

  • 事務訊息不僅可以實作應用之間的解耦，又能保證資料的最終一致性
  • 同時將傳統的大事務可以被拆分為小事務，能提升效率
  • 不會因為某一個關聯應用的不可用導致整體回滾，從而最大限度保證核心系統的可用性

• 缺點

  • 不能實時保證資料一致性
  • 極端情況下需要人工補償，比如 假如生產者成功處理本地業務，消費者始終消費不成功

Seata介紹

• 分布式事務框架

  • TX-LCN：支持2PC、TCC等多種模式
    • https://github.com/codingapi/tx-lcn
    • 更新慢（個人感覺處于停滯狀態）
  • Seata：支持 AT、TCC、SAGA 和 XA 多種模式
    • https://github.com/seata/seata
    • 背靠阿里，專門團隊推廣

• 為啥選擇Seata呢

  • git地址
    • https://github.com/seata/seata
  • 背靠阿里，專門團隊推廣和技術團隊
  • 已經線上大規模使用且沒出現重大漏洞
  • 和主流微服務框架輕松整合
  • 社區活躍度高、檔案齊全、功能強大
    （圖片來源seata官網）
    
    

什么是Seata

• 一個開源的分布式事務框架, 由阿里中間件團隊發起的開源專案Fescar，后更名為Seata

• 中文檔案地址

  • http://seata.io/zh-cn/

• 詳細介紹
  是一款開源的分布式事務解決方案，致力于在微服務架構下提供高性能和簡單易用的分布式事務服務，
  在 Seata 開源之前，Seata 對應的內部版本在阿里經濟體內部一直扮演著分布式一致性中間件的角色，幫助經濟體平穩的度過歷年的雙11，對各BU業務進行了有力的支撐，
  經過多年沉淀與積累，商業化產品先后在阿里云、金融云進行售賣，
  2019.1 為了打造更加完善的技術生態和貧訓技術成果，Seata 正式宣布對外開源，未來 Seata 將以社區共建的形式幫助其技術更加可靠與完備

• Seata主要由三個重要組件組成：

• TC：Transaction Coordinator 事務協調器，管理全域的分支事務的狀態，用于全域性事務的提交和回滾，

• TM：Transaction Manager 事務管理器，用于開啟、提交或者回滾【全域事務】，

• RM：Resource Manager 資源管理器，用于分支事務上的資源管理，向TC注冊分支事務，上報分支事務的狀態，接受TC的命令來提交或者回滾分支事務

  • 傳統XA協議實作2PC方案的 RM 是在資料庫層，RM本質上就是資料庫自身；
  • Seata的RM是以jar包的形式嵌入在應用程式里面

• 架構：TC 為單獨部署的 Server 服務端，TM 和 RM 為嵌入到應用中的 Client 客戶端
  

XID

• TM 請求 TC 開啟一個全域事務, TC 會生成一個 XID 作為該全域事務的編號XID, XID會在微服務的呼叫鏈路中傳播，保證將多個微服務的子事務關聯在一起

一個典型的事務程序包括：

• A服務的TM 向 TC 申請開啟（Begin）一個全域事務，全域事務創建成功并生成一個全域唯一的 XID，
• A服務的RM向TC注冊分支事務
• A服務執行分支事務，對資料庫做操作
• A服務開始遠程呼叫B服務，并把XID 在微服務呼叫鏈路的背景關系中傳播，
• B服務的RM向TC注冊分支事務，并將其納入XID對應的全域事務的管轄
• B服務執行分支事務，向資料庫做操作
• 全域事務呼叫鏈處理完畢，TM 根據有無例外向 TC 發起針對 XID 的全域提交（Commit）或回滾（Rollback）決議，
• TC 調度 XID 下管轄的全部分支事務完成提交（Commit）或回滾（Rollback）請求，

• Seata 實作分布式事務，關鍵角色UNDO_LOG（回滾日志記錄表）
  在每個應用需要分布式事務的業務庫中創建這張表，這個表的核心作用是將業務資料在更新前后的資料鏡像組織成回滾日志，保存在UNDO_LOG表中，以便業務例外能隨時回滾這張表的sql陳述句在官網上提供了，有興趣的可以直接去官網學習，也可以關注一下我，之后來講解seata的生產運用）

seats有四種模式：只講最常用的AT

• AT

  • AT模式可以應對大多數的業務場景，并且基本可以做到無業務入侵、開發者無感知

  • 用戶只需關心自己的 業務SQL. AT 模式分為兩個階段，可以認為是2PC

    • 一階段：執行用戶SQL

    Seata 會攔截“業務 SQL”，找到“業務 SQL”要更新的業務資料，在業務資料被更新前，將其保存成“before image”，然后執行“業務 SQL”更新業務資料
    
    在業務資料更新之后，再將其保存成“after image”，最后生成行鎖
    
    以上操作全部在一個資料庫事務內完成，這樣保證了一階段操作的原子性
    

    • 二階段：seata框架自動生成提交或者回滾

    二階段提交: 因為“業務 SQL”在一階段已經提交至資料庫， 所以 Seata 框架只需將階段一保存的快照資料和行鎖刪掉，完成資料清理即可，
    
    
    二階段回滾: 還原業務資料, 回滾方式便是用“before image”還原業務資料；
    但在還原前要首先要校驗臟寫，對比“資料庫當前業務資料”和 “after image”
    如果兩份資料完全一致就說明沒有臟寫，可以還原業務資料，如果不一致就說明有臟寫，出現臟寫就需要轉人工處理 
    

• TCC

• Sage

• XA

歡迎點贊，評論區交流！
之后會不斷更新技術文章，歡迎關注！