五大分散式事務，你瞭解多少？

牧小農發表於2020-09-12
分散式

在這裡插入圖片描述

一、前言

事務（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;

十、小結

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

相關文章