分布式事務(wù)框架Seata
一、seata是什么

1. 在微服務(wù)架構(gòu)下，由于數(shù)據(jù)庫和應(yīng)用服務(wù)的拆分，導(dǎo)致原本一個(gè)事務(wù)單元中的多個(gè)
   DML 操作，變成了跨進(jìn)程或者跨數(shù)據(jù)庫的多個(gè)事務(wù)單元的多個(gè) DML 操作，
   而傳統(tǒng)的數(shù)據(jù)庫事務(wù)無法解決這類的問題，所以就引出了分布式事務(wù)的概念。
2. 分布式事務(wù)本質(zhì)上要解決的就是跨網(wǎng)絡(luò)節(jié)點(diǎn)的多個(gè)事務(wù)的數(shù)據(jù)一致性問題，業(yè)內(nèi)常
   見的解決方法有兩種
   a. 強(qiáng)一致性，就是所有的事務(wù)參與者要么全部成功，要么全部失敗，全局事務(wù)協(xié)
   調(diào)者需要知道每個(gè)事務(wù)參與者的執(zhí)行狀態(tài)，再根據(jù)狀態(tài)來決定數(shù)據(jù)的提交或者
   回滾！
   b. 最終一致性，也叫弱一致性，也就是多個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)的數(shù)據(jù)允許出現(xiàn)不一致的情
   況，但是在最終的某個(gè)時(shí)間點(diǎn)會(huì)達(dá)成數(shù)據(jù)一致。
   基于 CAP 定理我們可以知道，強(qiáng)一致性方案對(duì)于應(yīng)用的性能和可用性會(huì)有影響，所以
   對(duì)于數(shù)據(jù)一致性要求不高的場(chǎng)景，就會(huì)采用最終一致性算法。
3. 在分布式事務(wù)的實(shí)現(xiàn)上，對(duì)于強(qiáng)一致性，我們可以通過基于 XA 協(xié)議下的二階段提
   交來實(shí)現(xiàn)，對(duì)于弱一致性，可以基于 TCC 事務(wù)模型、可靠性消息模型等方案來實(shí)
   現(xiàn)。
4. 市面上有很多針對(duì)這些理論模型實(shí)現(xiàn)的分布式事務(wù)框架，我們可以在應(yīng)用中集成這
   些框架來實(shí)現(xiàn)分布式事務(wù)。而 Seata 就是其中一種，它是阿里開源的分布式事務(wù)解決方案，提供了高性能且簡單易用的分布式事務(wù)服務(wù)。

二、seata模塊
TC (Transaction Coordinator) - 事務(wù)協(xié)調(diào)者

維護(hù)全局和分支事務(wù)的狀態(tài)，驅(qū)動(dòng)全局事務(wù)提交或回滾。

TM (Transaction Manager) - 事務(wù)管理器

定義全局事務(wù)的范圍：開始全局事務(wù)、提交或回滾全局事務(wù)。

RM (Resource Manager) - 資源管理器

管理分支事務(wù)處理的資源，與TC交談以注冊(cè)分支事務(wù)和報(bào)告分支事務(wù)的狀態(tài)，并驅(qū)動(dòng)分支事務(wù)提交或回滾。

在 Seata 中，一個(gè)分布式事務(wù)的生命周期如下：

TM 請(qǐng)求 TC 開啟一個(gè)全局事務(wù)。TC 會(huì)生成一個(gè) XID 作為該全局事務(wù)的編號(hào)。
XID，會(huì)在微服務(wù)的調(diào)用鏈路中傳播，保證將多個(gè)微服務(wù)的子事務(wù)關(guān)聯(lián)在一起。
RM 請(qǐng)求 TC 將本地事務(wù)注冊(cè)為全局事務(wù)的分支事務(wù)，通過全局事務(wù)的 XID 進(jìn)行關(guān)聯(lián)。
TM 請(qǐng)求 TC 告訴 XID 對(duì)應(yīng)的全局事務(wù)是進(jìn)行提交還是回滾。
TC 驅(qū)動(dòng) RM 們將 XID 對(duì)應(yīng)的自己的本地事務(wù)進(jìn)行提交還是回滾。

Seata的XA模型：
RM一階段：

1）TM開啟全局事務(wù)

2）TM調(diào)用分支RM、RM將分支注冊(cè)到TC、RM執(zhí)行SQL(但不提交！)、RM將執(zhí)行狀態(tài)報(bào)告給TC

TC二階段：

1）TM提交全局事務(wù)

2）TC統(tǒng)計(jì)各分支狀態(tài)，如果都成功，則通知RM提交。如果失敗，則通知RM回滾。

Seata AT模型：
一階段：TM開啟全局事務(wù)、TM調(diào)用分支、RM注冊(cè)分支事務(wù)、RM記錄undolog日志、RM提交事務(wù)、TCC記錄各分支狀態(tài)

二階段：TM通知提交/回滾全局事務(wù)、TC檢查各分支事務(wù)狀態(tài)，成功，則刪除undolog日志，失敗，則根據(jù)undolog日志回滾。

臟寫問題：

如果一個(gè)A事務(wù)執(zhí)行sql并提交，另一個(gè)B事務(wù)也執(zhí)行提交，此時(shí)A事務(wù)進(jìn)行回滾，則會(huì)回滾為A記錄的undolog日志，而B事務(wù)的更新修改記錄會(huì)被忽略，出現(xiàn)了臟寫問題。

解決：引入全局鎖，在A事務(wù)提價(jià)事務(wù)釋放DB鎖之前，申請(qǐng)全局鎖，而此時(shí)如果B事務(wù)進(jìn)行操作修改，在執(zhí)行更新數(shù)據(jù)庫操作前會(huì)獲取全局鎖，獲取失敗，則無法更新，不斷重試，但不能一直讓其重試，否則A嘗試獲取B占用的DB鎖則會(huì)造成死鎖，一般讓其重試30秒，然后失敗則放棄其占有的DB鎖，執(zhí)行失敗。A鎖此時(shí)就能獲取DB鎖，執(zhí)行回滾，然后再釋放全局鎖。

又引來新問題：如果是另一不歸seata管理的事務(wù)的？全局鎖失敗！

XA也自動(dòng)帶來了解決的方案：

1）首先記錄更新前的記錄

2）記錄更新后的記錄。

完整正確的執(zhí)行流程如下：

1）原數(shù)據(jù)假設(shè)為100，undolog記錄100這個(gè)數(shù)值。

2）A事務(wù)獲取DB鎖將數(shù)據(jù)修改為90，此時(shí)undolog記錄這條90。

3）A事務(wù)獲取全局鎖，并提交事務(wù)釋放DB數(shù)據(jù)庫鎖

4）A事務(wù)回滾，在回滾為100前，會(huì)比較此時(shí)數(shù)據(jù)是否是90。假設(shè)，不歸Seata管理的B事務(wù)，不需要獲取全局鎖，然后成功獲取DB鎖并修改了數(shù)據(jù)為80，則此時(shí)A事務(wù)將90（A修改后）與80（B修改）比較，則回滾失敗。

Seata TCC模型：
Try: 判斷是否有可用數(shù)據(jù)，足夠則凍結(jié)可用數(shù)據(jù)。

Confirm: 完成資源的操作業(yè)務(wù)；要求try成功，confirm一定要成功。

Cancel: 預(yù)留資源釋放，可以理解為try方向操作。

階段1：檢查資源是否足夠，足夠則凍結(jié)資源，執(zhí)行try方法

階段2：執(zhí)行成功，則執(zhí)行Confirm方法刪除凍結(jié)資源。執(zhí)行失敗，執(zhí)行Canel邏輯，恢復(fù)凍結(jié)資源

四種事務(wù)優(yōu)缺點(diǎn)介紹：

XA：強(qiáng)一致性，無代碼侵入、但一階段事務(wù)不提交、會(huì)鎖住資源，導(dǎo)致性能低。需要依賴數(shù)據(jù)庫的事務(wù)特性。

AT：默認(rèn)，弱一致性，無代碼侵入，一階段事務(wù)直接提交，失敗則根據(jù)undolog日志回滾，隔離性引入全局鎖，但并發(fā)幾率低，所以性能會(huì)比XA好。

TCC：無需依賴關(guān)系型數(shù)據(jù)庫，基于資源預(yù)留隔離。try、confirm、canel需要人工手寫，而且需要考慮空懸掛、空回滾、冪等性判斷，較為復(fù)雜、性能最好，但成本太高。

Seaga:適用于長事務(wù)類型，無太多應(yīng)用場(chǎng)景。文章來源地址http://www.zghlxwxcb.cn/news/detail-683652.html

到了這里，關(guān)于分布式事務(wù)框架Seata的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！