五大分布式事務(wù)，你了解多少？

一、前言

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

簡(jiǎn)單的講就是：要么全部被執(zhí)行，要么就全部失敗。

那分布式事務(wù)，自然就是運(yùn)行在分布式系統(tǒng)中的事務(wù)，是由多個(gè)不同的機(jī)器上的事務(wù)組合而成的。同上，只有分布式系統(tǒng)中所有事務(wù)執(zhí)行了才能是成功，否則失敗。

事務(wù)的基本特征ACID：

• 原子性（Atomicity）： 一個(gè)事務(wù)是一個(gè)不可分割的工作單位，事務(wù)中包括的諸操作要么都做，要么都不做。

• 一致性： 指事務(wù)執(zhí)行前和執(zhí)行后，數(shù)據(jù)是完整的。

• 隔離性： 一個(gè)事務(wù)的執(zhí)行不能被其他事務(wù)干擾。即一個(gè)事務(wù)內(nèi)部的操作及使用的數(shù)據(jù)對(duì)并發(fā)的其他事務(wù)是隔離的，并發(fā)執(zhí)行的各個(gè)事務(wù)之間不能互相干擾。

• 持久性： 也稱(chēng)為永久性，一個(gè)事務(wù)一旦提交，它對(duì)數(shù)據(jù)庫(kù)中數(shù)據(jù)的改變就應(yīng)該是永久性的保存下來(lái)了。

二、分布式事務(wù)的目標(biāo)和實(shí)際應(yīng)用場(chǎng)景

分布式事務(wù)的目標(biāo)：解決多個(gè)獨(dú)立事務(wù)一致性的問(wèn)題。

比如說(shuō)我們有一個(gè)功能，訂單系統(tǒng)，橫跨了多個(gè)微服務(wù)，由于每個(gè)微服務(wù)不在一個(gè)庫(kù)，沒(méi)法用數(shù)據(jù)庫(kù)事務(wù)來(lái)保證事務(wù)，那么這個(gè)時(shí)候我們就可以使用分布式事務(wù)

例如： 商城項(xiàng)目，有用戶(hù)支付了一個(gè)訂單，在支付系統(tǒng)中，支付表進(jìn)行了更新，在另一個(gè)訂單系統(tǒng)中，訂單庫(kù)里面訂單的狀態(tài)就要變成已支付，那么在訂單表和支付表，他們?cè)诓煌膸?kù)，如何保證兩個(gè)數(shù)據(jù)庫(kù)之間的事務(wù)呢

支付操作：支付修改余額，修改訂單狀態(tài)

三、分布式事務(wù)解決方案

1. 二階段提交協(xié)議（2PC）

2. 三階段提交協(xié)議（3PC）

3. 補(bǔ)償事務(wù)（TCC）

4. 消息中間件實(shí)現(xiàn)

5. seata框架

四、 二階段提交協(xié)議（2PC）

基于XA協(xié)議的，采取強(qiáng)一致性，遵從ACID

2PC：（2階段提交協(xié)議），是基于XA/JTA規(guī)范。

4.1 XA

XA是由X/Open組織提出的分布式事務(wù)的架構(gòu)（或者叫協(xié)議）。XA架構(gòu)主要定義了 （全局）事務(wù)管理器（Transaction Manager）和（局部）資源管理器（Resource Manager）之間 的接口。

XA接口是雙向的系統(tǒng)接口，在事務(wù)管理器（Transaction Manager）以及一個(gè)或多個(gè)資源管理器（Resource Manager）之間形成通信橋梁。也就是說(shuō)，在基于XA的一個(gè)事務(wù)中，我們可以針對(duì)多個(gè)資源進(jìn)行事務(wù)管理，例如一個(gè)系統(tǒng)訪問(wèn)多個(gè)數(shù)據(jù)庫(kù)，或即訪問(wèn)數(shù)據(jù)庫(kù)、又訪問(wèn)像消息中間件這樣的資源。這樣我們就能夠?qū)崿F(xiàn)在多個(gè)數(shù)據(jù)庫(kù)和消息中間件直接實(shí)現(xiàn)全部提交、或全部取消的事務(wù)。XA規(guī)范不是java的規(guī)范，而是一種通用的規(guī)范。

4.2 JTA

JTA(Java Transaction API)，是J2EE的編程接口規(guī)范，它是XA協(xié)議的JAVA實(shí)現(xiàn)。它主要定義了：

一個(gè)事務(wù)管理器的接口javax.transaction.TransactionManager，定義了有關(guān)事務(wù)的開(kāi)始、提交、撤回等操作。一個(gè)滿(mǎn)足XA規(guī)范的資源定義接口javax.transaction.xa.XAResource，一種資源如果要支持JTA事務(wù)，就需要讓它的資源實(shí)現(xiàn)該XAResource接口，并實(shí)現(xiàn)該接口定義的兩階段提交相關(guān)的接口。

4.3 流程圖

4.4 提交過(guò)程

1.請(qǐng)求階段，（commit-request phase，或稱(chēng)表決階段，voting phase），步驟（1-5） 在請(qǐng)求階段，協(xié)調(diào)者將通知事務(wù)參與者準(zhǔn)備提交或取消事務(wù)，然后進(jìn)入表決過(guò)程。在表決過(guò)程中，參與者將告知協(xié)調(diào)者自己的決策：同意（事務(wù)參與者本地作業(yè)執(zhí)行成功）或取消（本地作業(yè)執(zhí)行故障）。

2.提交階段（commit phase），步驟（6-7） 在該階段，協(xié)調(diào)者將基于第一個(gè)階段的投票結(jié)果進(jìn)行決策：提交或取消。當(dāng)且僅當(dāng)所有的參與者同意提交事務(wù)協(xié)調(diào)者才通知所有的參與者提交事務(wù)，否則協(xié)調(diào)者將通知所有的參與者取消事務(wù)。參與者在接收到協(xié)調(diào)者發(fā)來(lái)的消息后將執(zhí)行響應(yīng)的操作。

4.5 缺點(diǎn)

• 單點(diǎn)故障：事務(wù)的發(fā)起、提交還是取消，均是由老大協(xié)調(diào)者管理的，只要協(xié)調(diào)者宕機(jī)，那就涼涼了。

• 同步阻塞缺點(diǎn)：從上面介紹以及例子可看出，我們的參與系統(tǒng)中在沒(méi)收到老大的真正提交還是取消事務(wù)指令的時(shí)候，就是鎖定當(dāng)前的資源，并不真正的做些事務(wù)相關(guān)操作，所以，整個(gè)分布式系統(tǒng)環(huán)境就是阻塞的。

• 數(shù)據(jù)不一致缺點(diǎn)：就是說(shuō)在老大協(xié)調(diào)者向小弟們發(fā)送真正提交事務(wù)的時(shí)候，部分網(wǎng)路故障，造成部分系統(tǒng)沒(méi)收到真正的指令，那么就會(huì)出現(xiàn)部分提交部分沒(méi)提交，因此，這就會(huì)導(dǎo)致數(shù)據(jù)的不一致。

4.6 無(wú)法解決的問(wèn)題

當(dāng)協(xié)調(diào)者出錯(cuò)，同時(shí)參與者也出錯(cuò)時(shí)，兩階段無(wú)法保證事務(wù)執(zhí)行的完整性?？紤]協(xié)調(diào)者再發(fā)出commit消息之后宕機(jī)，而唯一接收到這條消息的參與者同時(shí)也宕機(jī)了。那么即使有了新的協(xié)調(diào)者，這條事務(wù)的狀態(tài)也是不確定的，沒(méi)人知道事務(wù)是否被已經(jīng)提交。知道的人已經(jīng)被滅口了。

五、 三階段提交協(xié)議（3PC）

采取強(qiáng)一致性，遵從ACID。在二階段上增加了：超時(shí)和預(yù)提交機(jī)制。有這三個(gè)主階段，canCommit、preCommit、doCommit這三個(gè)階段

5.1 流程圖

5.2 流程

1.CanCommit階段： 3PC的CanCommit階段其實(shí)和2PC的準(zhǔn)備階段很像。協(xié)調(diào)者向參與者發(fā)送commit請(qǐng)求，參與者如果可以提交就返回Yes響應(yīng)，否則返回No響應(yīng)。

2.PreCommit階段： Coordinator根據(jù)Cohort的反應(yīng)情況來(lái)決定是否可以繼續(xù)事務(wù)的PreCommit操作。

根據(jù)響應(yīng)情況，有以下兩種可能。A.假如Coordinator從所有的Cohort獲得的反饋都是Yes響應(yīng)，那么就會(huì)進(jìn)行事務(wù)的預(yù)執(zhí)行：發(fā)送預(yù)提交請(qǐng)求。Coordinator向Cohort發(fā)送PreCommit請(qǐng)求，并進(jìn)入Prepared階段。事務(wù)預(yù)提交。Cohort(一群大兵)接收到PreCommit請(qǐng)求后，會(huì)執(zhí)行事務(wù)操作，并將undo和redo信息記錄到事務(wù)日志中。響應(yīng)反饋。如果Cohort成功的執(zhí)行了事務(wù)操作，則返回ACK響應(yīng)，同時(shí)開(kāi)始等待最終指令。

B.假如有任何一個(gè)Cohort向Coordinator發(fā)送了No響應(yīng)，或者等待超時(shí)之后，Coordinator都沒(méi)有接到Cohort的響應(yīng)，那么就中斷事務(wù)：發(fā)送中斷請(qǐng)求。Coordinator向所有Cohort發(fā)送abort請(qǐng)求。中斷事務(wù)。Cohort收到來(lái)自Coordinator的abort請(qǐng)求之后（或超時(shí)之后，仍未收到Cohort的請(qǐng)求），執(zhí)行事務(wù)的中斷。

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

執(zhí)行提交 A.發(fā)送提交請(qǐng)求。Coordinator接收到Cohort發(fā)送的ACK響應(yīng)，那么他將從預(yù)提交狀態(tài)進(jìn)入到提交狀態(tài)。并向所有Cohort發(fā)送doCommit請(qǐng)求。B.事務(wù)提交。Cohort接收到doCommit請(qǐng)求之后，執(zhí)行正式的事務(wù)提交。并在完成事務(wù)提交之后釋放所有事務(wù)資源。C.響應(yīng)反饋。事務(wù)提交完之后，向Coordinator發(fā)送ACK響應(yīng)。D.完成事務(wù)。Coordinator接收到所有Cohort的ACK響應(yīng)之后，完成事務(wù)。

中斷事務(wù) 協(xié)調(diào)者沒(méi)有接收到參與者發(fā)送的ACK響應(yīng)，那么就執(zhí)行中斷事務(wù)。

A.發(fā)送中斷請(qǐng)求 協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求 B.事務(wù)回滾 參與者接收到abort請(qǐng)求之后，利用其在階段二記錄的undo信息來(lái)執(zhí)行事務(wù)的回滾操作，并在完成回滾之后釋放所有的事務(wù)資源。C.反饋結(jié)果 參與者完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送ACK消息 D.中斷事務(wù) 協(xié)調(diào)者接收到參與者反饋的ACK消息之后，執(zhí)行事務(wù)的中斷。

5.3 缺點(diǎn)

如果進(jìn)入PreCommit后，Coordinator發(fā)出的是abort請(qǐng)求，假設(shè)只有一個(gè)Cohort收到并進(jìn)行了abort操作， 而其他對(duì)于系統(tǒng)狀態(tài)未知的Cohort會(huì)根據(jù)3PC選擇繼續(xù)Commit，此時(shí)系統(tǒng)狀態(tài)發(fā)生不一致性。

5.4 2PC 和 3PC 的區(qū)別

加了詢(xún)問(wèn)，增大成功概率。

對(duì)于協(xié)調(diào)者(Coordinator)和參與者(Cohort)都設(shè)置了超時(shí)機(jī)制（在2PC中，只有協(xié)調(diào)者擁有超時(shí)機(jī)制，即如果在一定時(shí)間內(nèi)沒(méi)有收到cohort的消息則默認(rèn)失敗）。協(xié)調(diào)者掛了，參與者等待超時(shí)后，默認(rèn)提交事務(wù)。有一丟進(jìn)步。

如果參與者異常了，協(xié)調(diào)者也異常了，會(huì)造成其他參與者提交。

在2PC的準(zhǔn)備階段和提交階段之間，插入預(yù)提交階段，使3PC擁有CanCommit、PreCommit、DoCommit三個(gè)階段。PreCommit是一個(gè)緩沖，保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。

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

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

BASE：全稱(chēng)是，Basically Avaliable（基本可用），Soft state（軟狀態(tài)），Eventually consistent（最終一致性）三個(gè)短語(yǔ)的縮寫(xiě)，來(lái)自eBay的架構(gòu)師提出。

• Basically Avaliable： 就是在分布式系統(tǒng)環(huán)境中，允許犧牲掉部分不影響主流程的功能的不可用，將其降級(jí)以確保核心服務(wù)的正?？捎?。

• Soft state： 就是指在事務(wù)中，我們?cè)试S系統(tǒng)存在中間狀態(tài)，且并不影響我們這個(gè)系統(tǒng)。就拿數(shù)據(jù)庫(kù)的主從復(fù)制來(lái)說(shuō)，是完全允許復(fù)制的時(shí)候有延時(shí)的發(fā)生的。

• Eventually consistent： 還是以數(shù)據(jù)庫(kù)主從復(fù)制為例說(shuō)，雖然主從復(fù)制有小延遲，但是很快最終就數(shù)據(jù)保持一致了。

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

七、TCC

解決方案：TCC（Try、Confirm、Cancel），兩階段補(bǔ)償型方案。

從名字可以看出，實(shí)現(xiàn)一個(gè)事務(wù)，需要定義三個(gè)API：預(yù)先占有資源，確認(rèn)提交實(shí)際操作資源，取消占有=回滾。

如果后兩個(gè)環(huán)節(jié)執(zhí)行一半失敗了，記錄日志，補(bǔ)償處理，通知人工。

2PC：是資源層面的分布式事務(wù)，一直會(huì)持有資源的鎖。 如果跨十幾個(gè)庫(kù)，一下鎖這么多數(shù)據(jù)庫(kù)，會(huì)導(dǎo)致，極度浪費(fèi)資源。降低了吞吐量。TCC：在業(yè)務(wù)層面的分布式事務(wù)，最終一致性，不會(huì)一直持有鎖。將鎖的粒度變小，每操作完一個(gè)庫(kù)，就釋放了鎖。

都是相對(duì)的：如果每天只有一個(gè)請(qǐng)求，用2PC 比 TCC 要性能高。因?yàn)閠cc多了多次接口調(diào)用。而此時(shí)的2PC 不怕占用資源，反正就一個(gè)調(diào)用。高并發(fā)場(chǎng)景下TCC 優(yōu)勢(shì)要大。

八、消息中間件實(shí)現(xiàn)

消息隊(duì)列柔性事務(wù)流程圖：

1、操作支付表，然后在事件表里面插入一條數(shù)據(jù)，狀態(tài)為new狀態(tài)，放到數(shù)據(jù)庫(kù)，這個(gè)（1、2、3）操作都是在一個(gè)事務(wù)中，因?yàn)樗麄兌际且粋€(gè)庫(kù)

2、定時(shí)任務(wù)讀取事件表，發(fā)送隊(duì)列，發(fā)送成功以后，將事件表new的狀態(tài)改為（published），監(jiān)聽(tīng)事件表，插入一條數(shù)據(jù)到事件表

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

表設(shè)計(jì)：

CREATE TABLE `t_order_event` ( `id` int(16) NOT NULL, `order_type` varchar(32) DEFAULT NULL COMMENT '事件類(lèi)型（支付表支付完成，訂單表修改狀態(tài)）', `process` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT '事件環(huán)節(jié)（new,published,processed)', `content` varchar(255) DEFAULT NULL COMMENT '事件內(nèi)容，保存事件發(fā)生時(shí)需要傳遞的數(shù)據(jù)', `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 是一款開(kāi)源的分布式事務(wù)解決方案，致力于提供高性能和簡(jiǎn)單易用的分布式事務(wù)服務(wù)。Seata 將為用戶(hù)提供了 AT、TCC、SAGA 和 XA 事務(wù)模式，為用戶(hù)打造一站式的分布式解決方案。

官網(wǎng)Api（強(qiáng)烈推薦觀看）： 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 # 此服務(wù)的地址 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、創(chuàng)建數(shù)據(jù)庫(kù)，并建表

分支事務(wù)表： branchtable全局事務(wù)表： globaltable全局鎖： lock_table

注意：表的結(jié)構(gòu)不能錯(cuò)

5、在每個(gè)庫(kù)中增加 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;

十、小結(jié)

以上就是分布式事務(wù)的介紹，有不懂的小伙伴可以在討論留言，小農(nóng)看到了會(huì)第一時(shí)間回復(fù)大家的，也歡迎各位小伙伴對(duì)文中有不足的地方補(bǔ)充和交流，謝謝，大家加油