五大分布式事務，你了解多少？-有解無憂

在這里插入圖片描述

一、前言

事務（Transaction）：一般是指要做的或所做的事情，由 事務開始(begin transaction) 和 事務結束(end transaction) 之間執行的全體操作組成，

簡單的講就是：要么全部被執行，要么就全部失敗，

那分布式事務，自然就是運行在分布式系統中的事務，是由多個不同的機器上的事務組合而成的，同上，只有分布式系統中所有事務執行了才能是成功，否則失敗，

事務的基本特征ACID：

原子性（Atomicity）： 一個事務是一個不可分割的作業單位，事務中包括的諸操作要么都做，要么都不做，
一致性： 指事務執行前和執行后，資料是完整的，
隔離性： 一個事務的執行不能被其他事務干擾，即一個事務內部的操作及使用的資料對并發的其他事務是隔離的，并發執行的各個事務之間不能互相干擾，
持久性： 也稱為永久性，一個事務一旦提交，它對資料庫中資料的改變就應該是永久性的保存下來了，

在這里插入圖片描述

二、分布式事務的目標和實際應用場景

分布式事務的目標：解決多個獨立事務一致性的問題，

比如說我們有一個功能，訂單系統，橫跨了多個微服務，由于每個微服務不在一個庫，沒法用資料庫事務來保證事務，那么這個時候我們就可以使用分布式事務

例如： 商城專案，有用戶支付了一個訂單，在支付系統中，支付表進行了更新，在另一個訂單系統中，訂單庫里面訂單的狀態就要變成已支付，那么在訂單表和支付表，他們在不同的庫，如何保證兩個資料庫之間的事務呢

支付操作：支付修改余額，修改訂單狀態

三、分布式事務解決方案

二階段提交協議（2PC）
三階段提交協議（3PC）
補償事務（TCC）
訊息中間件實作
seata框架

四、二階段提交協議（2PC）

基于XA協議的，采取強一致性，遵從ACID

2PC：（2階段提交協議），是基于XA/JTA規范，

4.1 XA

XA是由X/Open組織提出的分布式事務的架構（或者叫協議），XA架構主要定義了 （全域）事務管理器（Transaction Manager）和（區域）資源管理器（Resource Manager）之間 的介面，

XA介面是雙向的系統介面，在事務管理器（Transaction Manager）以及一個或多個資源管理器（Resource Manager）之間形成通信橋梁，也就是說，在基于XA的一個事務中，我們可以針對多個資源進行事務管理，例如一個系統訪問多個資料庫，或即訪問資料庫、又訪問像訊息中間件這樣的資源，這樣我們就能夠實作在多個資料庫和訊息中間件直接實作全部提交、或全部取消的事務，XA規范不是java的規范，而是一種通用的規范，

4.2 JTA

JTA(Java Transaction API)，是J2EE的編程介面規范，它是XA協議的JAVA實作，它主要定義了：

一個事務管理器的介面javax.transaction.TransactionManager，定義了有關事務的開始、提交、撤回等操作，
一個滿足XA規范的資源定義介面javax.transaction.xa.XAResource，一種資源如果要支持JTA事務，就需要讓它的資源實作該XAResource介面，并實作該介面定義的兩階段提交相關的介面，

4.3 流程圖

二階段提交協議流程圖

4.4 提交程序

1.請求階段，（commit-request phase，或稱表決階段，voting phase），步驟（1-5）
在請求階段，協調者將通知事務參與者準備提交或取消事務，然后進入表決程序，
在表決程序中，參與者將告知協調者自己的決策：同意（事務參與者本地作業執行成功）或取消（本地作業執行故障），

2.提交階段（commit phase），步驟（6-7）
在該階段，協調者將基于第一個階段的投票結果進行決策：提交或取消，
當且僅當所有的參與者同意提交事務協調者才通知所有的參與者提交事務，否則協調者將通知所有的參與者取消事務，
參與者在接收到協調者發來的訊息后將執行回應的操作，

4.5 缺點

單點故障：事務的發起、提交還是取消，均是由老大協調者管理的，只要協調者宕機，那就涼涼了，
同步阻塞缺點：從上面介紹以及例子可看出，我們的參與系統中在沒收到老大的真正提交還是取消事務指令的時候，就是鎖定當前的資源，并不真正的做些事務相關操作，所以，整個分布式系統環境就是阻塞的，
資料不一致缺點：就是說在老大協調者向小弟們發送真正提交事務的時候，部分網路故障，造成部分系統沒收到真正的指令，那么就會出現部分提交部分沒提交，因此，這就會導致資料的不一致，

4.6 無法解決的問題

當協調者出錯，同時參與者也出錯時，兩階段無法保證事務執行的完整性，
考慮協調者再發出commit訊息之后宕機，而唯一接收到這條訊息的參與者同時也宕機了，
那么即使有了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交，知道的人已經被滅口了，

五、三階段提交協議（3PC）

采取強一致性，遵從ACID，
在二階段上增加了：超時和預提交機制，
有這三個主階段，canCommit、preCommit、doCommit這三個階段

5.1 流程圖

在這里插入圖片描述

5.2 流程

1.CanCommit階段： 3PC的CanCommit階段其實和2PC的準備階段很像，協調者向參與者發送commit請求，參與者如果可以提交就回傳Yes回應，否則回傳No回應，

2.PreCommit階段： Coordinator根據Cohort的反應情況來決定是否可以繼續事務的PreCommit操作，

根據回應情況，有以下兩種可能，
A.假如Coordinator從所有的Cohort獲得的反饋都是Yes回應，那么就會進行事務的預執行：
發送預提交請求，Coordinator向Cohort發送PreCommit請求，并進入Prepared階段，
事務預提交，Cohort(一群大兵)接收到PreCommit請求后，會執行事務操作，并將undo和redo資訊記錄到事務日志中，
回應反饋，如果Cohort成功的執行了事務操作，則回傳ACK回應，同時開始等待最終指令，

B.假如有任何一個Cohort向Coordinator發送了No回應，或者等待超時之后，Coordinator都沒有接到Cohort的回應，那么就中斷事務：
發送中斷請求，Coordinator向所有Cohort發送abort請求，
中斷事務，Cohort收到來自Coordinator的abort請求之后（或超時之后，仍未收到Cohort的請求），執行事務的中斷，

3.DoCommit階段： 該階段進行真正的事務提交，也可以分為以下兩種情況:

執行提交
A.發送提交請求，Coordinator接收到Cohort發送的ACK回應，那么他將從預提交狀態進入到提交狀態，并向所有Cohort發送doCommit請求，
B.事務提交，Cohort接收到doCommit請求之后，執行正式的事務提交，并在完成事務提交之后釋放所有事務資源，
C.回應反饋，事務提交完之后，向Coordinator發送ACK回應，
D.完成事務，Coordinator接收到所有Cohort的ACK回應之后，完成事務，

中斷事務
協調者沒有接收到參與者發送的ACK回應，那么就執行中斷事務，

A.發送中斷請求
協調者向所有參與者發送abort請求
B.事務回滾
參與者接收到abort請求之后，利用其在階段二記錄的undo資訊來執行事務的回滾操作，并在完成回滾之后釋放所有的事務資源，
C.反饋結果
參與者完成事務回滾之后，向協調者發送ACK訊息
D.中斷事務
協調者接收到參與者反饋的ACK訊息之后，執行事務的中斷，

5.3 缺點

如果進入PreCommit后，Coordinator發出的是abort請求，假設只有一個Cohort收到并進行了abort操作，
而其他對于系統狀態未知的Cohort會根據3PC選擇繼續Commit，此時系統狀態發生不一致性，

5.4 2PC 和 3PC 的區別

加了詢問，增大成功概率，

對于協調者(Coordinator)和參與者(Cohort)都設定了超時機制（在2PC中，只有協調者擁有超時機制，即如果在一定時間內沒有收到cohort的訊息則默認失敗），協調者掛了，參與者等待超時后，默認提交事務，有一丟進步，

如果參與者例外了，協調者也例外了，會造成其他參與者提交，

在2PC的準備階段和提交階段之間，插入預提交階段，使3PC擁有CanCommit、PreCommit、DoCommit三個階段，
PreCommit是一個緩沖，保證了在最后提交階段之前各參與節點的狀態是一致的，

六、基于訊息的最終一致性形式

采取最終一致性，遵從BASE理論，

BASE：全稱是，Basically Avaliable（基本可用），Soft state（軟狀態），Eventually consistent（最終一致性）三個短語的縮寫，來自eBay的架構師提出，

Basically Avaliable： 就是在分布式系統環境中，允許犧牲掉部分不影響主流程的功能的不可用，將其降級以確保核心服務的正常可用，
Soft state： 就是指在事務中，我們允許系統存在中間狀態，且并不影響我們這個系統，就拿資料庫的主從復制來說，是完全允許復制的時候有延時的發生的，
Eventually consistent： 還是以資料庫主從復制為例說，雖然主從復制有小延遲，但是很快最終就資料保持一致了，

分布式事務不可能100%解決，只能提高成功概率，兩階段之間時間，毫秒級別，
補救措施：
定時任務補償，程式或腳本補償，
人工介入，

七、TCC

解決方案：TCC（Try、Confirm、Cancel），兩階段補償型方案，

從名字可以看出，實作一個事務，需要定義三個API：預先占有資源，確認提交實際操作資源，取消占有=回滾，

如果后兩個環節執行一半失敗了，記錄日志，補償處理，通知人工，

2PC：是資源層面的分布式事務，一直會持有資源的鎖，
	如果跨十幾個庫，一下鎖這么多資料庫，會導致，極度浪費資源，降低了吞吐量，
TCC：在業務層面的分布式事務，最終一致性，不會一直持有鎖，將鎖的粒度變小，每操作完一個庫，就釋放了鎖，
	

都是相對的：如果每天只有一個請求，用2PC 比 TCC 要性能高，因為tcc多了多次介面呼叫，而此時的2PC 不怕占用資源，反正就一個呼叫，高并發場景下TCC 優勢要大，

八、訊息中間件實作

訊息佇列柔性事務流程圖：
在這里插入圖片描述

1、操作支付表，然后在事件表里面插入一條資料，狀態為new狀態，放到資料庫，這個（1、2、3）操作都是在一個事務中，因為他們都是一個庫

2、定時任務讀取事件表，發送佇列，發送成功以后，將事件表new的狀態改為（published），監聽事件表，插入一條資料到事件表

3、定時任務讀庫是不是published事件表，如果是published事件表，更新訂單表，更新事件表為processed，這樣就將一個大事務，拆分成幾個幾個的小事務

表設計：

CREATE TABLE `t_order_event` (
  `id` int(16) NOT NULL,
  `order_type` varchar(32) DEFAULT NULL COMMENT '事件型別（支付表支付完成，訂單表修改狀態）',
  `process` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT '事件環節（new,published,processed)',
  `content` varchar(255) DEFAULT NULL COMMENT '事件內容，保存事件發生時需要傳遞的資料',
  `create_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP,
  `update_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

九、seata框架

Seata 是一款開源的分布式事務解決方案，致力于提供高性能和簡單易用的分布式事務服務，Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務模式，為用戶打造一站式的分布式解決方案，

官網Api（強烈推薦觀看）： https://seata.io/zh-cn/docs/overview/what-is-seata.html

seata下載地址： https://seata.io/zh-cn/blog/download.html

流程圖：
在這里插入圖片描述

操作步驟：

1、下載seata server

https://seata.io/zh-cn/blog/download.html

2、修改file.conf

service {
  #transaction service group mapping
  #修改，可不改,my_test_tx_group隨便起名字，
  vgroup_mapping.my_test_tx_group = "default"
  #only support when registry.type=file, please don't set multiple addresses
  # 此服務的地址
  default.grouplist = "127.0.0.1:8091"
  #disable seata
  disableGlobalTransaction = false
}

store {
  ## store mode: file、db
  # 修改
  mode = "db"

  ## file store property
  file {
    ## store location dir
    dir = "sessionStore"
  }

  ## database store property
  #db資訊修改
  db {
    ## the implement of javax.sql.DataSource, such as DruidDataSource(druid)/BasicDataSource(dbcp) etc.
	
    datasource = "druid"
    ## mysql/oracle/h2/oceanbase etc.
    db-type = "mysql"
    driver-class-name = "com.mysql.cj.jdbc.Driver"
    url = "jdbc:mysql://127.0.0.1:3306/seata-server?useUnicode=true&useSSL=false&characterEncoding=utf8&serverTimezone=Asia/Shanghai"
    user = "root"
    password = "root"
  }
}

3、修改registry.conf

registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
  #修改
  type = "eureka"

  nacos {
    serverAddr = "localhost"
    namespace = ""
    cluster = "default"
  }
  #修改
  eureka {
    serviceUrl = "http://localhost:8761/eureka"
    application = "default"
    weight = "1"
  }
  redis {
    serverAddr = "localhost:6379"
    db = "0"
  }
  zk {
    cluster = "default"
    serverAddr = "127.0.0.1:2181"
    session.timeout = 6000
    connect.timeout = 2000
  }
  consul {
    cluster = "default"
    serverAddr = "127.0.0.1:8500"
  }
  etcd3 {
    cluster = "default"
    serverAddr = "http://localhost:2379"
  }
  sofa {
    serverAddr = "127.0.0.1:9603"
    application = "default"
    region = "DEFAULT_ZONE"
    datacenter = "DefaultDataCenter"
    cluster = "default"
    group = "SEATA_GROUP"
    addressWaitTime = "3000"
  }
  file {
    name = "file.conf"
  }
}

config {
  # file、nacos 、apollo、zk、consul、etcd3
  type = "file"

  nacos {
    serverAddr = "localhost"
    namespace = ""
  }
  consul {
    serverAddr = "127.0.0.1:8500"
  }
  apollo {
    app.id = "seata-server"
    apollo.meta = "http://192.168.1.204:8801"
  }
  zk {
    serverAddr = "127.0.0.1:2181"
    session.timeout = 6000
    connect.timeout = 2000
  }
  etcd3 {
    serverAddr = "http://localhost:2379"
  }
  file {
    name = "file.conf"
  }
}

4、創建資料庫，并建表

分支事務表： branch_table
全域事務表： global_table
全域鎖： lock_table

注意：表的結構不能錯

5、在每個庫中增加 undo_log，用于回滾

CREATE TABLE `undo_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `context` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int(11) NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  `ext` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;

十、小結

以上就是分布式事務的介紹，有不懂的小伙伴可以在討論留言，小農看到了會第一時間回復大家的，也歡迎各位小伙伴對文中有不足的地方補充和交流，謝謝，大家加油

牧小農

CSDN認證博客專家 Java后端大資料資料庫

專注Java領域開發，從使用技巧到底層原始碼，從資料庫到大資料，從多執行緒到高并發，你想要的這里都有，一個人可能走得更快，但是一群人會走得更遠，快快訂閱關注牧小農，讓我們一起走的更遠，關注小農，將知識打包帶走，大家加油

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/37180.html

標籤：其他

上一篇：msf工具之木馬程式制作以及偽裝

下一篇：【JAVA】滴滴-2021校招在線筆試-DE資料開發試卷-0913

五大分布式事務，你了解多少？

一、前言

二、分布式事務的目標和實際應用場景

三、分布式事務解決方案

四、 二階段提交協議（2PC）

4.1 XA

4.2 JTA

4.3 流程圖

4.4 提交程序

4.5 缺點

4.6 無法解決的問題

五、 三階段提交協議（3PC）

5.1 流程圖

5.2 流程

5.3 缺點

5.4 2PC 和 3PC 的區別

六、基于訊息的最終一致性形式

七、TCC

八、訊息中間件實作

九、seata框架

1、下載seata server

2、修改file.conf

3、修改registry.conf

4、創建資料庫，并建表

5、在每個庫中增加 undo_log，用于回滾

十、小結

四、二階段提交協議（2PC）

五、三階段提交協議（3PC）