1.本地事務(wù)和分布式事務(wù)概念

事務(wù)四大特性

• 原子性：事務(wù)不可再分
• 一致性：數(shù)據(jù)改變前后，總量必須一致
• 隔離性：事務(wù)之間相互隔離，互不干擾
• 持久性：事務(wù)一旦提交，數(shù)據(jù)就會持久化到磁盤，不能回滾

本地事務(wù)：所有的事務(wù)都是基于數(shù)據(jù)庫的，那么我們在代碼中加@Transactional其實(shí)是使用的數(shù)據(jù)庫的Begin/Commit/Rollback，底層使用的是動態(tài)代理。本地事務(wù)只能管理到當(dāng)前服務(wù)連接的那個數(shù)據(jù)庫的事務(wù)，如果一個事務(wù)中操作了多個數(shù)據(jù)庫在回顧的時候只能回滾當(dāng)前服務(wù)連接的那個數(shù)據(jù)庫，沒辦法回滾其它數(shù)據(jù)庫

分布式事務(wù)：用于解決在一個方法中操作多個數(shù)據(jù)庫的事務(wù)，分布式事務(wù)其實(shí)就是將多個數(shù)據(jù)庫加入到同一組事務(wù)中，當(dāng)某一個數(shù)據(jù)庫發(fā)生異常時整體回滾

2.分布式事務(wù)的解決方案

2.1 XA協(xié)議

• 簡單理解就是XA規(guī)范協(xié)議是一種事務(wù)協(xié)議，通過這種協(xié)議來通知數(shù)據(jù)庫事務(wù)的開始、結(jié)束、提交、以及回滾，XA 接口函數(shù)由數(shù)據(jù)庫廠商提供。XA協(xié)議使用二階段提交來處理分布式事務(wù)，說的更明白一點(diǎn)就是XA協(xié)議保證了分布式事務(wù)的原子性，要么都成功，要么都失敗。
• XA協(xié)議采用兩階段提交方式來管理分布式事務(wù)

2.2 2PC模式

2PC就是基于XA協(xié)議進(jìn)行實(shí)現(xiàn)的，采用兩階段提交 2PC（Two Phase Commitment Protocol）來管理分布式事務(wù)，所謂二階段是有兩個階段組成，一階段投票階段和二階段提交階段。同時它是由“事務(wù)協(xié)調(diào)器”和若干“事務(wù)執(zhí)行者”兩個角色組成。

第一階段：準(zhǔn)備階段（ 投票階段 ）

• 事務(wù)協(xié)調(diào)器向所有事務(wù)參與者發(fā)請求，詢問是否可以執(zhí)行提交操作(你們都可以執(zhí)行事務(wù)操作嗎？)，并開始等待各參與者節(jié)點(diǎn)的響應(yīng)。
• 事務(wù)參與者收到協(xié)調(diào)者的指令開始執(zhí)行事務(wù)操作但是不會提交事務(wù)，同時寫Undo log(寫操作之前首先將數(shù)據(jù)備份log,如果要回滾就從這個log進(jìn)行數(shù)據(jù)還原) 和 Redo log(修改數(shù)據(jù)在buffer pool緩沖池中修改，Redo log是對這個緩沖池的內(nèi)容做持久，避免修改的數(shù)據(jù)丟失) 。
• 如果參與者事務(wù)操作都執(zhí)行成功(注意哦，沒提交事務(wù)哦)，那么就會回復(fù) 事務(wù)協(xié)調(diào)器 “準(zhǔn)備OK” ，如果事務(wù)操作失敗，那么就會回復(fù)執(zhí)行者“準(zhǔn)備不OK”。

第二階段：提交階段

正常流程

• 事務(wù)協(xié)調(diào)器會收到參與者的回復(fù)，如果所有的參與者都回復(fù)“準(zhǔn)備ok”，意味著所有的參與者都可以完成事務(wù)操作，那么事務(wù)協(xié)調(diào)器會向每個事務(wù)參與者發(fā)送一個“commit” 提交事務(wù)指令(既然大家都可以進(jìn)行事務(wù)操作，那大家都提交事務(wù)把)
• 事務(wù)參與者收到指令就開始提交事務(wù)，然后會向事務(wù)協(xié)調(diào)器回復(fù)“完成”，事務(wù)協(xié)調(diào)器收到所有參與者都回復(fù)完成，事務(wù)完成

回滾流程

• 如果再第一階段事務(wù)協(xié)調(diào)器收到了某個事務(wù)參與者回復(fù)“準(zhǔn)備不ok”即事務(wù)操作執(zhí)行失敗，那么事務(wù)協(xié)調(diào)器會向所有的事務(wù)參與者發(fā)送“rollback”回滾執(zhí)行(有一個成員不ok,那大家都散了吧，今天的事情搞不成了)
• 事務(wù)參與者收到指令，回滾之前的事務(wù)操作，即：將數(shù)據(jù)還原到“Undo log”的數(shù)據(jù)，然后向事務(wù)協(xié)調(diào)者回復(fù)“回滾成功”，當(dāng)事務(wù)協(xié)調(diào)器收到所有的參與者回復(fù)“回滾成功”后，取消事務(wù)。

發(fā)送回滾指令

二階段提交的問題

• 二階段能保證分布式事務(wù)的原子性，但是也有一些明顯的缺陷。比如：在第一階段，如果參與者遲遲不回復(fù)協(xié)調(diào)者，就會造成事務(wù)的阻塞，性能不好。
• 單節(jié)點(diǎn)故障，如果協(xié)調(diào)器掛了，參與者會阻塞，比如在第二階段，如果事務(wù)協(xié)調(diào)器宕機(jī)，參與者沒辦法回復(fù)信息，長時間處于事務(wù)資源鎖定，造成阻塞(事務(wù)操作是要加鎖的)。
• 在第二階段，如果在事務(wù)協(xié)調(diào)器發(fā)出"commit"執(zhí)行后宕機(jī)，一部和參與者收到了消息提交了事務(wù)，而一部分沒有消息沒法做出事務(wù)提交操作，這樣就出現(xiàn)了數(shù)據(jù)不一致。
• 在第二階段，如果事務(wù)事務(wù)協(xié)調(diào)器發(fā)出“commit”指令后宕機(jī)，收到“commmit”指令的參與者也宕機(jī)了，那么事務(wù)最終變成了什么效果，提交了還是沒提交？沒有誰知道。

2.3 3PC模式

三階段提交（Three-phase commit），也叫三階段提交協(xié)議（Three-phase commit protocol），是二階段提交（2PC）的改進(jìn)版本，

3PC在2PC的功能上做了兩個改動，一是在協(xié)調(diào)者和事務(wù)參與者之間引入了超時機(jī)制，在第一階段和第二階段中插入一個準(zhǔn)備階段 ， 保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的，那么現(xiàn)在的三階段分為了：

• canCommit“詢問是否能提交，
• papreCommit”準(zhǔn)備提交階段 ，
• doCommit”提交階段。

第一階段“canCommit” :

• 事務(wù)協(xié)調(diào)者向事務(wù)參與者發(fā)送 canCommit 請求詢問是否能提交事務(wù)，然后等待所有事務(wù)參與者的返回
• 事務(wù)參與者接收到事務(wù)些調(diào)整的canCommit指令，然后自身認(rèn)為能夠提交事務(wù)則返回 “yes”否則返回“no”

第二階段“papreCommit”

事務(wù)協(xié)調(diào)者收到所有的事務(wù)參與者的canCmmit指令的反饋結(jié)果，這里有兩種情況，一是所有的反饋都是yes，二是有部分的事 務(wù)參與者返回No，后者反饋超時。

正常流程

• 如果事務(wù)協(xié)調(diào)者收到所有的事務(wù)參與者的canCmmit指令反饋結(jié)果都為YES，那么就進(jìn)入papreCommit階段。事務(wù)協(xié)調(diào)者向事務(wù)參與者發(fā)送 “papreCommit”指令。
• 事務(wù)參與者收到“papreCommit”指令，開始進(jìn)行事務(wù)操作，并將undo和redo信息記錄到事務(wù)日志中，如果順利執(zhí)行事務(wù)操作，則反饋ACK確認(rèn)信息，然后等待下一步指令。

中斷事務(wù)

• 如果事務(wù)協(xié)調(diào)者收到所有的事務(wù)參與者的canCmmit指令反饋結(jié)果出現(xiàn)了NO,或者等待超時，那么就執(zhí)行事務(wù)中斷，向所有的事務(wù)參與者發(fā)送“abort”中斷指令。
• 事務(wù)參與者接收到“abort”指令，中斷事務(wù)，當(dāng)然如果事務(wù)參與者遲遲未收到事務(wù)協(xié)調(diào)者的指令等待超時也會中斷事務(wù)。

第三階段“doCommit階段”

這里準(zhǔn)備提交事務(wù)了，這里有兩種情況，如果事務(wù)協(xié)調(diào)者收到所有的事務(wù)參與者的papreCommit指令反饋結(jié)果都是ACK,那么進(jìn)入doCommit階段,否則會中斷事務(wù)。

正常流程

• 事務(wù)協(xié)調(diào)者收到所有的事務(wù)參與者的papreCommit指令反饋結(jié)果都是ACK，然后向事務(wù)參與者發(fā)送“doCommit”指令，通知提交事務(wù)。
• 事務(wù)參與者收到“doCommit”指令，正式執(zhí)行事務(wù)提交，并且釋放所有事務(wù)資源，返回向事務(wù)協(xié)調(diào)者返回事務(wù)結(jié)果狀態(tài)“ACK”完成
• 事務(wù)協(xié)調(diào)者收到所有的事務(wù)參與者都返回ACK成功,完成事務(wù)。

中斷事務(wù)

• 事務(wù)協(xié)調(diào)者收到的事務(wù)參與者的papreCommit指令反饋結(jié)果有的不是ACK，那么事務(wù)協(xié)調(diào)者然后向事務(wù)參與者發(fā)送“abort”事務(wù)中斷指密令。
• 事務(wù)參與者收到“abort”事務(wù)指令，會根據(jù)unlog日志文件還原數(shù)據(jù)，然后釋放事務(wù)資源，然后向事務(wù)協(xié)調(diào)者發(fā)送回滾“ACK”消息
• 事務(wù)協(xié)調(diào)者收到所有的事務(wù)參與者都返回ACK消息,取消事務(wù)。

2.4 TCC事物補(bǔ)償

TCC(Try Confirm Cancel) 事務(wù)補(bǔ)償機(jī)制，即每一個操作都要做相應(yīng)的補(bǔ)償機(jī)制，即如何確認(rèn)操作成功，如果操作失敗如何撤銷事務(wù)。它分為三個階段

• Try : try的意思是嘗試，其實(shí)這個步驟是用來做業(yè)務(wù)的預(yù)處理，可以理解為是做一些準(zhǔn)備工作，等到Confirm之后這些操作才算成功。
• Confirm ：確認(rèn)，如果所有的事務(wù)參與者都try成功，執(zhí)行commit對業(yè)務(wù)做提交操作，或者可以理解成對try的工作作出確認(rèn)。
• Cancel：取消，如果try失敗需要回滾，即取消try的預(yù)處理操作

2.5 MQ消息最終一致性

大致流程是：

1.主業(yè)務(wù)方向發(fā)送一個“Prepared”準(zhǔn)備消息到MQ，這個消息還未被確認(rèn)，不會發(fā)生給消費(fèi)者，然后MQ向生產(chǎn)者發(fā)送確認(rèn)收到消息，然后主業(yè)務(wù)方執(zhí)行自己的業(yè)務(wù)，并提交本地事務(wù)，成功后向MQ確認(rèn)之前的“Prepared”消息發(fā)生給消費(fèi)者，如果失敗MQ將當(dāng)前半消息刪除，取消事務(wù)。

2.消息接受者方收到消息后執(zhí)行業(yè)務(wù)邏輯，提交本地事務(wù)，然后向MQ返回ACK確認(rèn)消息，如果ACK消息為成功，MQ則刪除當(dāng)前消息；如果消費(fèi)者消息接受失敗或返回ACK是失敗，會進(jìn)行重試，保證消息最終被消費(fèi)。直到16次后還是失敗，消息會進(jìn)入死信隊列，該消息不會被刪除，也不會重發(fā)，需要人工介入；

RocketMQ的事務(wù)消息：使用MQ的分布式事務(wù)是最終一致性

• 生成者發(fā)送一個半事務(wù)消息給MQ，MQ告訴生產(chǎn)者接收到了，此時生產(chǎn)者方就去執(zhí)行本地事務(wù)
• 如果執(zhí)行成功那么告訴MQ執(zhí)行Commit，如果本地事務(wù)失敗MQ執(zhí)行Rollback。那么MQ執(zhí)行Commit就是把此消息發(fā)送給消費(fèi)者，消費(fèi)者接收到消息之后執(zhí)行本地事務(wù)，如果執(zhí)行成功那么響應(yīng)ACK確認(rèn)成功，如果執(zhí)行失敗那么響應(yīng)ACK失敗，MQ接收到成功刪除此消息，如果失敗那么會再次發(fā)送，直到16次之后還是失敗那么進(jìn)入到死信隊列，此時就需要我們?nèi)斯とz查代碼手動發(fā)送消息再次消費(fèi)。如果MQ執(zhí)行Rollback那么就會把此消息進(jìn)行刪除。
• 如果避免生產(chǎn)者一直不提交commit或rollback還準(zhǔn)備了一個回查機(jī)制，調(diào)用我們寫的一個方法，在方法中去檢查生產(chǎn)者的本地事務(wù)是否執(zhí)行成功，如果成功提交commit，如果失敗提交rollback

2.6 Seata框架

seata(Simple Extensible Autonomous Transaction Architecture) 是 阿里巴巴開源的分布式事務(wù)中間件，致力于提供高性能，零入侵和簡單易用的分布式事務(wù)服務(wù)。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務(wù)模式，為用戶打造一站式的分布式解決方案。

Seata 的設(shè)計思路是將一個分布式事務(wù)可以理解成一個全局事務(wù)，下面掛了若干個分支事務(wù)，而一個分支事務(wù)是一個滿足 ACID 的本地事務(wù)，因此我們可以操作分布式事務(wù)像操作本地事務(wù)一樣。

Seata重要組成

• Transcation ID（XID） : 由事務(wù)協(xié)調(diào)者創(chuàng)建的全局唯一的事務(wù)ID
• Transaction Coordinator(TC) - 事務(wù)協(xié)調(diào)器：一個獨(dú)立運(yùn)行的組件，負(fù)責(zé)維護(hù)全局事務(wù)的運(yùn)行狀態(tài)，負(fù)責(zé)根據(jù)TM的指令協(xié)調(diào)并驅(qū)動全局事務(wù)的提交或回滾，負(fù)責(zé)向資源管理器發(fā)起事務(wù)提交，回滾指令。
• Transaction Manager - 事務(wù)管理器 ：控制全局事務(wù)的邊界，負(fù)責(zé)開啟一個全局事務(wù)，并最終發(fā)起全局提交或全局回滾的決議，通知TC提交或者回滾事務(wù)。
• Resource Manager(RM) - 資源管理器： 控制分支事務(wù)，負(fù)責(zé)分支事務(wù)注冊、負(fù)責(zé)向TC匯報分支事務(wù)狀態(tài)，并接收事務(wù)協(xié)調(diào)器的指令，驅(qū)動分支（本地）事務(wù)的提交和回滾

正常執(zhí)行流程：

• 系統(tǒng)啟動TM事務(wù)管理者以及RM資源管理者需要向事務(wù)協(xié)調(diào)器進(jìn)行提交注冊，可以看做是一種初始化。
• 在Bussiness的業(yè)務(wù)主方法上我們需要打上@GlobalTransationl注解，通過這個注解，事務(wù)管理器TM向事務(wù)協(xié)調(diào)者(TC)申請開啟一個全局分布式事務(wù),事務(wù)協(xié)調(diào)者創(chuàng)建全局事務(wù)后返回全局唯一的 XID,這個XID 會在涉及微服務(wù)的整個全局事務(wù)的上下文中進(jìn)行傳播。
• 業(yè)務(wù)開始，Bussiness通過Feign調(diào)用Order，并傳遞全局事務(wù)XID，Order在做寫操作的時候，RM資源管理器 (Order集成了RM)向事務(wù) 協(xié)調(diào)器TC 注冊本地分支事務(wù)，該分支事務(wù)歸屬于擁有相同 XID 的全局事務(wù)，同時事務(wù)協(xié)調(diào)者TC會返回一個分支事務(wù)ID：“branchId” 。說明一下：Seate通過代理DataSource向TC發(fā)起分子事務(wù)注冊的。
• 這個時候Order會正常的寫數(shù)據(jù)庫，然后會寫入一個undo log(這個日志文件記錄了數(shù)據(jù)庫修改前的數(shù)據(jù)，用來做回滾)，然后提交分支事務(wù)(注意，分支事務(wù)已經(jīng)提交了) ， 最后向TC上報事務(wù)處理狀態(tài)。當(dāng)然Account做的事情和Order是相同的。
• Order和Account都調(diào)用完成，代碼回到Business,這時TM事務(wù)管理器向TC事務(wù)協(xié)調(diào)者發(fā)起全局事務(wù)提交請求，TC向RM事務(wù)分支發(fā)起事務(wù)提交請求，RM(Order, Account)直接刪除到undo log日志文件即可，因?yàn)橹耙呀?jīng)提交了本地事務(wù)

異常執(zhí)行流程：

前面2個步驟都跟上面一樣，這里省略 ， 在第 3 步的時候，Order在可能因?yàn)槟撤N原因本地分支事務(wù)提交失敗了，那么RM會向TC上報一個失敗的事務(wù)狀態(tài)

在第 4 步 ，這個時候代碼回到Business,這時TM事務(wù)管理器會向TC事務(wù)協(xié)調(diào)者發(fā)起全局事務(wù)回滾請求，TC向RM事務(wù)分支發(fā)起事務(wù)回滾請求，RM(Order, Account)收到回滾指令，然后會解析undo log，指向反向操作，把數(shù)據(jù)還原到修改之前，刪除undo log,提交本地事務(wù)。

3.微服務(wù)整合seata

3.1導(dǎo)入依賴

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
</dependency>

3.2yaml配置seata

項目的yaml中對seata做配置

這里的tx-service-group: ${spring.application.name}-tx-group要和seataServer.properties中的保持一致

seata:
  enabled: true
  application-id: ${spring.application.name}
  tx-service-group: ${spring.application.name}-tx-group #it-fccar-service-driver-tx-group
  #對應(yīng)seataServer.properties中的service.vgroupMapping.it-drive-service-driver-tx-group=default
  config:
    type: nacos
    nacos:
      server-addr: ${NACOS_HOST:8.137.85.173:8848}:${NACOS_PORT:8848}
      username: nacos
      password: nacos #賬號再nacos管理界面配置
      namespace: fccar-dev #取pom.xml中的命名空間
      data-id: seataServer.properties
      group: DEFAULT_GROUP #重要，和seataServer.properties保持一樣
  registry:
    type: nacos
    nacos:
      application: service-seata #seata的服務(wù)名
      server-addr: ${NACOS_HOST:8.137.85.173:8848}:${NACOS_PORT:8848}
      username: nacos
      password: nacos #賬號再nacos管理界面配置
      namespace: fccar-dev #取pom.xml中的命名空間
      group: DEFAULT_GROUP
  enable-auto-data-source-proxy: true #開啟seata的datasource自動代理

在啟動類貼注解開啟seata ， 因?yàn)閥aml做了配置，下面注解可以不要

@EnableAutoDataSourceProxy(dataSourceProxyMode="AT",useJdkProxy=false)

3.3.開啟全局事務(wù)

開啟全局事務(wù),在入口方法貼注解

注意：只在業(yè)務(wù)入口的微服務(wù)的方法上貼即可

@GlobalTransactional(name = "driver-wechat-register",rollbackFor = Exception.class)

到此這篇關(guān)于SpringBoot集成Seata的文章就介紹到這了,更多相關(guān)SpringBoot集成Seata內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！