簡(jiǎn)介

我們都知道 Seata 是一個(gè)分布式事務(wù)的解決方案，今天我們就來(lái)帶大家了解一下什么是分布式事務(wù)，首先我們先來(lái)了解一下基礎(chǔ)的知識(shí)——事務(wù)，我們先來(lái)了解一下事務(wù)的概念是什么。

基本概念

事務(wù)四部分構(gòu)成— ACID：

• A(Atomic)：原子性，構(gòu)成事務(wù)的所有操作，要么全部執(zhí)行成功，要么全部執(zhí)行失敗，不會(huì)出現(xiàn)部分成功或者部分失敗的情況。
• C(Consistency)：一致性，在事務(wù)執(zhí)行前后，數(shù)據(jù)庫(kù)的一致性約束沒(méi)有被破壞，比如，小勇去銀行取100塊錢，取之前是600，取之后應(yīng)該是400，取之前和取之后的數(shù)據(jù)為正確數(shù)值為一致性，如果取出100，而銀行里面的錢沒(méi)有減少，要么小勇要笑醒了，這個(gè)就沒(méi)有達(dá)到一致性的要求。
• I(Isolation):隔離性，數(shù)據(jù)庫(kù)中的事務(wù)一般都是并發(fā)的，隔離性是只在并發(fā)的兩個(gè)事務(wù)執(zhí)行過(guò)程互不干擾，一個(gè)事務(wù)在執(zhí)行過(guò)程中不能看到其他事務(wù)運(yùn)行過(guò)程的中間狀態(tài)，通過(guò)配置事務(wù)隔離級(jí)別可以避免臟讀，重復(fù)讀等問(wèn)題。
• D(Durability)：持久性，當(dāng)事務(wù)完成之后，事務(wù)對(duì)數(shù)據(jù)的更改會(huì)被持久化到數(shù)據(jù)庫(kù)，且不會(huì)回滾。

事務(wù)分為兩部分：本地事務(wù)和分布式事務(wù)。

本地事務(wù)：

在計(jì)算機(jī)系統(tǒng)中，比較多的是通過(guò)關(guān)系型數(shù)據(jù)庫(kù)來(lái)控制事務(wù)，這是利用數(shù)據(jù)庫(kù)本身的事務(wù)特性進(jìn)行實(shí)現(xiàn)的，因?yàn)閼?yīng)用主要靠關(guān)系型數(shù)據(jù)庫(kù)來(lái)維持事務(wù)，加上數(shù)據(jù)庫(kù)和應(yīng)用都在同一個(gè)服務(wù)器，所以基于關(guān)系型數(shù)據(jù)的事務(wù)又被稱為本地事務(wù)。

分布式事務(wù)：

分布式事務(wù)是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理者分別位于不同的分布式系統(tǒng)的不同節(jié)點(diǎn)之上，且屬于不同的應(yīng)用，分布式事務(wù)需要保證這些操作要么全部成功，要么全部失敗，分布式事務(wù)就是為了保證在不同服務(wù)器上數(shù)據(jù)庫(kù)數(shù)據(jù)的一致性。

Seata 的設(shè)計(jì)思路是將多個(gè)服務(wù)器的本地事務(wù)組成一個(gè)全局事務(wù)，下面若干個(gè)本地事務(wù)，都能滿足ACID，最好形成一個(gè)整的分布式事務(wù)，操作分布式事務(wù)就像是操作本地事務(wù)一樣。

分布式系統(tǒng)會(huì)把一個(gè)應(yīng)用拆分為多個(gè)可獨(dú)立部署的服務(wù)，服務(wù)于服務(wù)之間通常需要遠(yuǎn)程協(xié)作才能完成事務(wù)的操作，這種分布式系統(tǒng)環(huán)境下由于不同的服務(wù)之間通過(guò)網(wǎng)絡(luò)遠(yuǎn)程協(xié)作完成的事務(wù)被稱為分布式事務(wù)，例如供應(yīng)鏈系統(tǒng)中，訂單創(chuàng)建（生成訂單、扣減庫(kù)存、履約通知發(fā)貨）等。

在上圖中我們可以看出，只要涉及到操作多個(gè)數(shù)據(jù)源，就會(huì)產(chǎn)生事務(wù)的問(wèn)題，我們?cè)趯?shí)際開發(fā)中應(yīng)該要避免這這個(gè)你問(wèn)題的出現(xiàn)，但是雖然系統(tǒng)的拓展，應(yīng)用和應(yīng)用之間必然會(huì)產(chǎn)生應(yīng)用之間事務(wù)的分離，當(dāng)微服務(wù)架構(gòu)中，主要有MQ和Seata，在了解他們之前，我們先來(lái)了解一下分布式事務(wù)是怎樣組成，以及如何實(shí)現(xiàn)的。

分布式事務(wù)

分布式事務(wù)是什么？

分布式事務(wù)指的是事務(wù)的參與者，支持事務(wù)的服務(wù)器，資源服務(wù)器分別位于分布式系統(tǒng)的不同節(jié)點(diǎn)之上，通常一個(gè)分布式事物中會(huì)涉及到對(duì)多個(gè)數(shù)據(jù)源或業(yè)務(wù)系統(tǒng)的操作。

隨著互聯(lián)網(wǎng)的發(fā)展，從之前的單一項(xiàng)目逐漸向分布式服務(wù)做轉(zhuǎn)換，現(xiàn)如今微服務(wù)在各個(gè)公司已經(jīng)普遍存在，而當(dāng)時(shí)的本地事務(wù)已經(jīng)無(wú)法滿足分布式應(yīng)用的要求，因此分布式服務(wù)之間事務(wù)的協(xié)調(diào)就產(chǎn)生了問(wèn)題，如果做到多個(gè)服務(wù)之間事務(wù)的操作，能夠像本地事務(wù)一樣遵循ACID原則，成為一個(gè)難題，但是在大牛們不斷的探索下，終于找到了分布式事務(wù)存在兩大理論依據(jù)：CAP定律和BASE理論。

CAP定律

CAP定律由一致性(C)、可用性(A)、分區(qū)容錯(cuò)性(P)組成，在分布式系統(tǒng)中，不可能同時(shí)滿足Consistency(一致性)/Availability(可用性)/Partition tolerance(分區(qū)容錯(cuò)性) 三個(gè)特性，最多只能同時(shí)滿足其中兩項(xiàng)。

• 一致性(C)：在分布式系統(tǒng)中所有的數(shù)據(jù)備份，在同一時(shí)刻保持一致的特性，所有的應(yīng)用節(jié)點(diǎn)訪問(wèn)的都是同一份最新的數(shù)據(jù)副本。
• 可用性(A): 當(dāng)集群中一部分節(jié)點(diǎn)故障以后，集群整體能夠響應(yīng)客戶端的讀寫請(qǐng)求，對(duì)數(shù)據(jù)更新具備高可用性。
• 分區(qū)容錯(cuò)性(P): 如果系統(tǒng)在規(guī)定時(shí)間限制內(nèi)不能達(dá)成數(shù)據(jù)的一致性，就表示要發(fā)生分區(qū)的情況，當(dāng)前操作需要在C和A之間做出選擇，讓系統(tǒng)能夠在遇到網(wǎng)絡(luò)故障等情況的時(shí)候，任然能夠保證對(duì)外提供滿足一致性或者可用性的服務(wù)。

在上圖中我們可以看到，當(dāng)我們用戶去購(gòu)物車?yán)锩纥c(diǎn)擊下單結(jié)算的時(shí)候，首先會(huì)經(jīng)過(guò)我們庫(kù)存服務(wù)，判斷庫(kù)存是否足夠，當(dāng)庫(kù)存滿足，扣減庫(kù)存以后，我們需要將數(shù)據(jù)同步到其他服務(wù)器上，這一步是為了保證數(shù)據(jù)的結(jié)果的一致性，這個(gè)時(shí)候如果網(wǎng)絡(luò)產(chǎn)生波動(dòng)了，我們的系統(tǒng)需要保證分區(qū)容錯(cuò)性，也就是我們必須容忍網(wǎng)絡(luò)所帶來(lái)的一些問(wèn)題，此時(shí)想保證一致性，就需要舍棄可用性。

但是如果為了保證高可用性，那么在高并發(fā)的情況下，是無(wú)法保證在限定時(shí)間內(nèi)給出響應(yīng)，由于網(wǎng)絡(luò)的不可靠，我們的訂單服務(wù)可能無(wú)法拿到最新的數(shù)據(jù)，但是我們要給用戶做出響應(yīng)，那么也無(wú)法保證一致性，所以AP是無(wú)法保證強(qiáng)一致性的。

如果既想要保證高可用又想要保證一致性，必須在網(wǎng)絡(luò)良好的情況下才能實(shí)現(xiàn)，那么解決方法只有一個(gè)，那就是需要將庫(kù)存、訂單、履約放到一起，但是這個(gè)就上去了我們微服務(wù)的作用，也就不再是分布式系統(tǒng)了。

在分布式系統(tǒng)中，分區(qū)容錯(cuò)性是必須存在的，我們只能在一致性和可用性上取舍，在這種條件下就誕生了BASE理論。

BASE理論

BASE由 基本可用 (Basically Available)、軟狀態(tài) (Soft state)和 最終一致性 (Eventually consistent) 三個(gè)構(gòu)建而成，是對(duì)CAP中一致性和可用性權(quán)衡的結(jié)果，來(lái)源于對(duì)互聯(lián)網(wǎng)系統(tǒng)分布式實(shí)踐的總結(jié)，是基于CAP定理逐步演化而來(lái)的，核心四系那個(gè)是及時(shí)無(wú)法做到強(qiáng)一致性，但是每個(gè)應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹?lái)使系統(tǒng)達(dá)到最終一致性。

1. 基本可用：基本可用是指當(dāng)分布式系統(tǒng)出現(xiàn)不可預(yù)知故障的時(shí)候，允許損失部分可用性，但是這里并不是說(shuō)表示系統(tǒng)不可以用，主要體現(xiàn)為以下幾點(diǎn):

• 響應(yīng)時(shí)間上的損失，在正常情況下，一個(gè)在線搜索引擎需要在0.5秒之內(nèi)返回給用戶響應(yīng)的查詢結(jié)果，但是由于出現(xiàn)故障，查詢結(jié)果的響應(yīng)時(shí)間增加了1-2秒。
• 系統(tǒng)功能上的損失，在正常情況下，一個(gè)電子商務(wù)網(wǎng)站上進(jìn)行購(gòu)物，消費(fèi)者幾乎能夠順利的完成每一單操作，但是在一些節(jié)日大促銷購(gòu)物高峰期的時(shí)候，由于網(wǎng)站上購(gòu)買量的猛增，為了保證系統(tǒng)的穩(wěn)定性，部分消費(fèi)者可能會(huì)引導(dǎo)到一個(gè)臨時(shí)降級(jí)處理的頁(yè)面或者提示。

基本可用的意思是，對(duì)于我們的核心服務(wù)是可以使用的，其他的服務(wù)可以適當(dāng)?shù)慕档晚憫?yīng)時(shí)間，甚至是進(jìn)行服務(wù)降級(jí)處理，在當(dāng)前中，庫(kù)存和訂單肯定是核心服務(wù)，至于我們的發(fā)貨系統(tǒng)在當(dāng)時(shí)只要保證基本可用就行，它的同步可以慢一點(diǎn)或者延遲更高，等待流量高峰過(guò)去以后，在進(jìn)行恢復(fù)。

2. 軟狀態(tài)：軟狀態(tài)是指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認(rèn)為該中間狀態(tài)的存在不會(huì)影響系統(tǒng)的整體可用性，即允許系統(tǒng)不用節(jié)點(diǎn)的數(shù)據(jù)副本之間進(jìn)行數(shù)據(jù)同步的過(guò)程存在延時(shí)。

軟狀態(tài)的意思是說(shuō)，當(dāng)我們大量下單的時(shí)候，扣減庫(kù)存時(shí)，流量激增，這個(gè)時(shí)候如果大量訪問(wèn)到庫(kù)存或者訂單中，可能會(huì)將系統(tǒng)弄垮，這個(gè)過(guò)程中我們可以允許數(shù)據(jù)的同步存在延遲，不影響整體系統(tǒng)的使用。

3. 最終一致性：最終一致性強(qiáng)調(diào)的是所有數(shù)據(jù)副本，在經(jīng)過(guò)一段時(shí)間的同步之后，最終都能夠達(dá)到一個(gè)一致的狀態(tài)，因此，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達(dá)到一致，而不是需要實(shí)時(shí)保證系統(tǒng)的強(qiáng)一致性。

經(jīng)過(guò)流量高峰期以后，經(jīng)過(guò)一段時(shí)間的同步，從中間狀態(tài)最后變成數(shù)據(jù)最終一致性，保證各個(gè)服務(wù)數(shù)據(jù)的一致性。

二階段提交(2PC)

2PC即兩階段提交協(xié)議，是將整個(gè)事務(wù)流程分為兩個(gè)階段，P是指準(zhǔn)備階段，C是指提交階段。

就好比我們?nèi)CC買冰淇淋吃，那剛好有活動(dòng)，第二杯半價(jià)，但是你是一個(gè)人，這個(gè)時(shí)候剛好有個(gè)小姐姐過(guò)來(lái)，正在考慮買不買冰淇淋吃，這個(gè)時(shí)候你和她提出了AA，也就會(huì)說(shuō)只有當(dāng)你和她都同意買這個(gè)的時(shí)候，才能購(gòu)買到，如果兩個(gè)人中有一個(gè)不同意那么就不能買這個(gè)冰淇淋吃。

階段一：準(zhǔn)備階段 老板要求你先進(jìn)行付款，你同意付款完成后，再要求女方付款，女方同意付款完成。

階段二：提交階段 都付款完成，老板出餐，兩個(gè)人都吃到冰淇淋。

這個(gè)例子就組成了一個(gè)事務(wù)。如果男女雙方有一個(gè)人拒絕付款，那么老板就不會(huì)出餐，并且會(huì)把已收取的錢原路退回。

整個(gè)事務(wù)過(guò)程是由事務(wù)管理器和參與者組成的，店老板就是事務(wù)管理器，你和那個(gè)女孩就是參與者，事務(wù)管理器決策整個(gè)分布式事務(wù)在計(jì)算機(jī)中關(guān)系數(shù)據(jù)支持兩階段提交協(xié)議：

• 準(zhǔn)備階段(Prepare phase)：事務(wù)管理器給每個(gè)參與者發(fā)送Prepare? 消息，每個(gè)數(shù)據(jù)庫(kù)參與者在本地執(zhí)行事務(wù)，并寫本地的Undo/Redo 日志，此時(shí)事務(wù)沒(méi)有提交。

undo日志是記錄修改前的數(shù)據(jù)，用于數(shù)據(jù)庫(kù)回滾。

Redo 日志是記錄修改后的數(shù)據(jù)，用于提交事務(wù)寫入數(shù)據(jù)文件。

• 提交階段(commit phase)：如果事務(wù)管理器收到了參與者的執(zhí)行失敗或者超時(shí)消息時(shí)，直接給每個(gè)參與者發(fā)送(Rollback?) 消息，如果收到參與者都成功，發(fā)送(Commit) 參與者根據(jù)事務(wù)管理器的指令執(zhí)行提交或者回滾操作，并釋放事務(wù)處理過(guò)程中使用的資源。

成功提交：

事務(wù)管理器向所有參與者發(fā)送事務(wù)內(nèi)容，詢問(wèn)是否準(zhǔn)備好了，等待參與者的響應(yīng)，各個(gè)參與者事務(wù)節(jié)點(diǎn)執(zhí)行事務(wù)操作，并將 Undo和Redo 信息記入事務(wù)日志中。如果參與者成功執(zhí)行事務(wù)操作，反饋事務(wù)管理器YES操作，表示事務(wù)可以執(zhí)行，假如協(xié)調(diào)者從所有的參與者或得反饋都是Yes響應(yīng)，那么就會(huì)執(zhí)行事務(wù)提交。

失?。?/h4>

假如任何一個(gè)參與者向事務(wù)管理器反饋了No指令，或者等待超時(shí)之后，事務(wù)管理器無(wú)法接收到所有參與者的反饋?lái)憫?yīng)，那么中斷事務(wù)，發(fā)送回滾請(qǐng)求，事務(wù)管理器向所有參與者節(jié)點(diǎn)發(fā)送 RollBack 請(qǐng)求，參與者接收到 RollBack 請(qǐng)求后，會(huì)利用在階段一記錄的Undo信息執(zhí)行事務(wù)的回滾操作，在完成回滾之后釋放事務(wù)執(zhí)行期間占用的資源，參與者在完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送ACK消息，事務(wù)管理器在接受到所有參與者反饋的ACK消息之后，完成事務(wù)中斷。

三階段提交(3PC)

3PC 主要是為了解決兩階段提交協(xié)議的單點(diǎn)故障問(wèn)題和縮小參與者阻塞范圍。是二階段提交（2PC）的改進(jìn)版本，引入?yún)⑴c節(jié)點(diǎn)的超時(shí)機(jī)制之外，3PC把2PC的準(zhǔn)備階段分成事務(wù)詢問(wèn)（該階段不會(huì)阻塞）和事務(wù)預(yù)提交,則三個(gè)階段分別為 CanCommit、PreCommit、DoCommit。

CanCommit 詢問(wèn)狀態(tài)

CanCommit階段 協(xié)調(diào)者(Coordinator)會(huì)向參與者(Participant) 發(fā)送CanCommit消息，詢問(wèn)是否可以執(zhí)行操作，參與者收到消息后，表示能夠執(zhí)行，會(huì)返回給協(xié)調(diào)者能夠執(zhí)行的(yes)命令。

如果參與者不能執(zhí)行，會(huì)返回No命令,釋放資源，結(jié)束事務(wù)。

PreCommit 預(yù)提交

PreCommit 階段如果協(xié)調(diào)者收到參與者返回的狀態(tài)值為YES，那么就證明它們都有能力去執(zhí)行這個(gè)操作，那么協(xié)調(diào)者就會(huì)向所有參與者 發(fā)送 PreCommit 消息，協(xié)調(diào)者收到 PreCommit消息后，回去執(zhí)行本地事務(wù)，如果執(zhí)行成功會(huì)將本地事務(wù)保存到 undo和redo 后，再返回給協(xié)調(diào)者YES指令，如果執(zhí)行本地事務(wù)失敗，返回協(xié)調(diào)者No,只要協(xié)調(diào)者收到一個(gè)執(zhí)行失敗，給所有參與者發(fā)送中斷事務(wù)消息，參與者收到消息后，對(duì)事務(wù)進(jìn)行回滾操作。

在這個(gè)階段參與者和協(xié)調(diào)者都引入了超時(shí)機(jī)制，如果參與者沒(méi)有收到，協(xié)調(diào)者的消息，或者協(xié)調(diào)者沒(méi)有收到參與者返回的預(yù)執(zhí)行結(jié)果狀態(tài)，在等待超時(shí)之后，事務(wù)會(huì)中斷，避免了事務(wù)的阻塞。

協(xié)調(diào)者向參與者發(fā)送PreCommit?，如果參與者執(zhí)行成功，返回yes。

如果參與者執(zhí)行失敗，只有有一個(gè)返回No到協(xié)調(diào)者，協(xié)調(diào)者會(huì)向參與者發(fā)送中斷事務(wù)的消息，參與者回滾事務(wù)。

DoCommit 提交

協(xié)調(diào)者收到所有參與者返回的狀態(tài)都是YES，這時(shí)協(xié)調(diào)者會(huì)向所有的參與者都發(fā)送 DoCommit ，參與者收到 DoCommit 后，會(huì)真正的提交事務(wù)，當(dāng)事務(wù)提交成功后，返回協(xié)調(diào)者YES狀態(tài)，表示我已經(jīng)完成事務(wù)的提交了，協(xié)調(diào)者收到所有參與者都返回YES狀態(tài)后，那么就完成了本次事務(wù)。

如果某個(gè)參與者返回No消息，協(xié)調(diào)者發(fā)送中斷事務(wù)消息(abort)，給參與者們，參與者回滾事務(wù)。

3PC是2PC的升級(jí)版，引入了超時(shí)機(jī)制，解決了單點(diǎn)故障引起的事務(wù)阻塞問(wèn)題，但是3PC依然不能解決事務(wù)一致性的問(wèn)題，因?yàn)樵贒oCommit階段，如果由于網(wǎng)絡(luò)或者超時(shí)等原則導(dǎo)致參與者收不到協(xié)調(diào)者發(fā)送過(guò)來(lái)的 中斷事務(wù)消息(abort) ，過(guò)了這個(gè)時(shí)間后，參與者會(huì)提交事務(wù)，本來(lái)是應(yīng)該進(jìn)行回滾，提交事務(wù)后，會(huì)導(dǎo)致數(shù)據(jù)不一致的問(wèn)題出現(xiàn)，2PC雖然在網(wǎng)絡(luò)故障情況下存在強(qiáng)一致性被破壞的問(wèn)題，但是故障恢復(fù)以后能保證最終一致性，3PC雖然有超時(shí)時(shí)間，解決了阻塞，提高了可用性，但是犧牲了一致性，如果針對(duì)網(wǎng)絡(luò)波動(dòng)問(wèn)題導(dǎo)致數(shù)據(jù)問(wèn)題這一點(diǎn)上，2PC是優(yōu)于3PC的。

Seata

官網(wǎng)：https://seata.io/zh-cn/docs/overview/what-is-seata.html。

Seata 是一款開源的分布式事務(wù)解決方案，致力于提供高性能和簡(jiǎn)單易用的分布式事務(wù)服務(wù)。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務(wù)模式，為用戶打造一站式的分布式解決方案。

在微服務(wù)系統(tǒng)中，一般業(yè)務(wù)會(huì)被拆分成獨(dú)立的模塊，在官方提供的結(jié)構(gòu)圖中，我們可以看到當(dāng)前主要分為三個(gè)模塊。

• 庫(kù)存服務(wù)：對(duì)于商品庫(kù)存信息進(jìn)行增加或者減少操作。
• 訂單服務(wù)：根據(jù)用戶指定商品生成訂單。
• 賬戶服務(wù)：從用戶賬戶中扣除余額，增加積分，維護(hù)地址信息等等。

在當(dāng)前架構(gòu)中，用戶挑選心儀的商品下單后，需要三個(gè)服務(wù)來(lái)完成操作，每一個(gè)服務(wù)的內(nèi)部都擁有一個(gè)獨(dú)立的本地事務(wù)來(lái)保證當(dāng)前服務(wù)數(shù)據(jù)的強(qiáng)一致性，但是三個(gè)服務(wù)組成的全局事務(wù)一致性就沒(méi)辦法進(jìn)行保證，那么Seata就是來(lái)解決這個(gè)問(wèn)題的。

Seata術(shù)語(yǔ)

官網(wǎng)地址：https://seata.io/zh-cn/docs/overview/terminology.html。

在了解Seata之前，我們先來(lái)了解一下 Seata 幾個(gè)關(guān)鍵的概念：

1. TC(Transaction Coordinator)事務(wù)協(xié)調(diào)者：維護(hù)全局和分支事務(wù)的狀態(tài)，驅(qū)動(dòng)全局事務(wù)提交或者回滾。
2. TM(Transaction Manager) 事務(wù)管理者： 發(fā)起者，同時(shí)一個(gè)RM的一種，定義全局事務(wù)的范圍，開始全局事務(wù)，提交或回滾全局事務(wù)。
3. RM(Resource Manager) 資源管理器：  參與事務(wù)的微服務(wù)，管理分支事務(wù)處理的資源，與TC交談以注冊(cè)分支事務(wù)和報(bào)告分支事務(wù)的狀態(tài)，并驅(qū)動(dòng)分支事務(wù)提交或回滾。

Seata 2PC

一階段： 業(yè)務(wù)數(shù)據(jù)和回滾日志記錄在同一個(gè)本地事務(wù)中提交，釋放本地鎖和連接資源。

二階段： 提交異步化，非?？焖俚赝瓿伞；貪L通過(guò)一階段的回滾日志進(jìn)行反向補(bǔ)償。

一階段本地事務(wù)提交前，需要確保先拿到 全局鎖 。拿不到全局鎖 ，不能提交本地事務(wù)。拿全局鎖的嘗試被限制在一定范圍內(nèi)，超出范圍將放棄，并回滾本地事務(wù)，釋放本地鎖。

在數(shù)據(jù)庫(kù)本地事務(wù)隔離級(jí)別讀已提交或以上的基礎(chǔ)上，Seata（AT 模式）的默認(rèn)全局隔離級(jí)別是 讀未提交。

如果應(yīng)用在特定場(chǎng)景下，必需要求全局的 讀已提交 ，目前 Seata 的方式是通過(guò) SELECT FOR UPDATE 語(yǔ)句的代理。

Seata執(zhí)行流程分析：

每個(gè)RM 使用 DataSourceProxy 鏈接數(shù)據(jù)路，目的是使用 ConnectionProxy ，使用數(shù)據(jù)源和數(shù)據(jù)代理的目的是在第一階段將 undo和業(yè)務(wù)數(shù)據(jù)放在一個(gè)本地事務(wù)中提交，這樣就保存了只要有業(yè)務(wù)操作就一定會(huì)有dudo日志。

在第一階段中，undo存放了數(shù)據(jù)修改前后修改的值，是為了事務(wù)回滾做好準(zhǔn)備，在第一階段完成就已經(jīng)將分支事務(wù)提交了，也就釋放了鎖資源。

TM開啟全局事務(wù)開始，將XID全局事務(wù)ID放在事務(wù)上下文中，通過(guò)feign調(diào)用將XID傳入下游服務(wù)器中，每個(gè)分支事務(wù)將自己的 Branch ID分支事務(wù)ID和XID進(jìn)行關(guān)聯(lián)。

在第二階段全局事務(wù)提交，TC會(huì)通知各個(gè)分支參與者提交分支事務(wù)，在第一階段已經(jīng)提交了分支事務(wù)，在這里各參與者只需要?jiǎng)h除undo即可，并且可以異步執(zhí)行。

如果某一個(gè)分支事務(wù)異常了，第二階段全局事務(wù)回滾操作，TC會(huì)通知各個(gè)分支參與者回滾分支事務(wù)，通過(guò)XID和Branch-ID找到對(duì)應(yīng)的回滾日志，通過(guò)回滾日志生成的反向SQL執(zhí)行，完成分支事務(wù)回滾到之前的狀態(tài)。

Seata 下載安裝

下載地址：https://github.com/seata/seata/releases。

解壓后找到conf目錄。

我們?cè)趩?dòng)seata之前，首先要啟動(dòng)nacos，其實(shí)也很簡(jiǎn)單，只需要下載nacos后啟動(dòng)就行，不知道nacos怎么操作的看這里的介紹nacos基礎(chǔ)介紹?，啟動(dòng)好之后，我們?cè)賮?lái)啟動(dòng)seata，bin目錄下seata-server.bat。

如果我們看到8091端口在監(jiān)聽，并且在nacos看到服務(wù)注冊(cè)上去了，就表示我們seata啟動(dòng)成功了。

總結(jié)

到這里我們關(guān)于分布式事務(wù)的和seata的介紹就講完了，其實(shí)關(guān)于分布式還有MQ實(shí)現(xiàn)可靠消息最終一致性，MQ主要解決了兩個(gè)功能：本地事務(wù)與消息發(fā)送的原子性問(wèn)題。事務(wù)參與方接收消息的可靠性。