web開發(fā)中的分布式事務(wù)是怎樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的閩侯網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 二階段提交協(xié)議(2PC)

• 三階段提交協(xié)議(3PC)

• 補償事務(wù)(TCC)

• 消息中間件實現(xiàn)

• seata框架

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

基于XA協(xié)議的，采取強一致性，遵從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)以及一個或多個資源管理器(Resource  Manager)之間形成通信橋梁。也就是說，在基于XA的一個事務(wù)中，我們可以針對多個資源進(jìn)行事務(wù)管理，例如一個系統(tǒng)訪問多個數(shù)據(jù)庫，或即訪問數(shù)據(jù)庫、又訪問像消息中間件這樣的資源。這樣我們就能夠?qū)崿F(xiàn)在多個數(shù)據(jù)庫和消息中間件直接實現(xiàn)全部提交、或全部取消的事務(wù)。XA規(guī)范不是java的規(guī)范，而是一種通用的規(guī)范。

4.2 JTA

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

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

4.3 流程圖

4.4 提交過程

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

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

4.5 缺點

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

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

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

4.6 無法解決的問題

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

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

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

5.1 流程圖

5.2 流程

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

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

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

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

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

執(zhí)行提交  A.發(fā)送提交請求。Coordinator接收到Cohort發(fā)送的ACK響應(yīng)，那么他將從預(yù)提交狀態(tài)進(jìn)入到提交狀態(tài)。并向所有Cohort發(fā)送doCommit請求。B.事務(wù)提交。Cohort接收到doCommit請求之后，執(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)者沒有接收到參與者發(fā)送的ACK響應(yīng)，那么就執(zhí)行中斷事務(wù)。

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

5.3 缺點

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

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

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

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

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

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

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

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

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

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

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

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

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

七、TCC

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

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

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

2PC：是資源層面的分布式事務(wù)，一直會持有資源的鎖。

如果跨十幾個庫，一下鎖這么多數(shù)據(jù)庫，會導(dǎo)致，極度浪費資源。降低了吞吐量。

TCC：在業(yè)務(wù)層面的分布式事務(wù)，最終一致性，不會一直持有鎖。將鎖的粒度變小，每操作完一個庫，就釋放了鎖。

都是相對的：如果每天只有一個請求，用2PC 比 TCC 要性能高。因為tcc多了多次接口調(diào)用。而此時的2PC  不怕占用資源，反正就一個調(diào)用。高并發(fā)場景下TCC 優(yōu)勢要大。

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

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

1、操作支付表，然后在事件表里面插入一條數(shù)據(jù)，狀態(tài)為new狀態(tài)，放到數(shù)據(jù)庫，這個(1、2、3)操作都是在一個事務(wù)中，因為他們都是一個庫

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

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

表設(shè)計：

CREATE TABLE `t_order_event` (   `id` int(16) NOT NULL,   `order_type` varchar(32) DEFAULT NULL COMMENT '事件類型（支付表支付完成，訂單表修改狀態(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ù)據(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 是一款開源的分布式事務(wù)解決方案，致力于提供高性能和簡單易用的分布式事務(wù)服務(wù)。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA  事務(wù)模式，為用戶打造一站式的分布式解決方案。

官網(wǎng)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   # 此服務(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/h3/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ù)庫，并建表

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

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

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;

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。