天天看點
傳回

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

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

一、前言

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

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

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

事務的基本特征ACID：

  • 原子性（Atomicity）： 一個事務是一個不可分割的工作機關，事務中包括的諸操作要麼都做，要麼都不做。
  • 一緻性： 指事務執行前和執行後，資料是完整的。
  • 隔離性： 一個事務的執行不能被其他事務幹擾。即一個事務内部的操作及使用的資料對并發的其他事務是隔離的，并發執行的各個事務之間不能互相幹擾。
  • 持久性： 也稱為永久性，一個事務一旦送出，它對資料庫中資料的改變就應該是永久性的儲存下來了。
五大分布式事務，你了解多少？

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

分布式事務的目标： 解決多個獨立事務一緻性的問題。

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

例如： 商城項目，有使用者支付了一個訂單，在支付系統中，支付表進行了更新，在另一個訂單系統中，訂單庫裡面訂單的狀态就要變成已支付，那麼在訂單表和支付表，他們在不同的庫，如何保證兩個資料庫之間的事務呢

支付操作：支付修改餘額，修改訂單狀态

三、分布式事務解決方案

  1. 二階段送出協定（2PC）
  2. 三階段送出協定（3PC）
  3. 補償事務（TCC）
  4. 消息中間件實作
  5. 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;

十、小結

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

上一篇: 01.泛型Generic
下一篇: 【高并發】高并發秒殺系統架構解密，不是所有的秒殺都是秒殺！