1.分布式事務(wù)概論

1.常規(guī)事務(wù)

1.1事務(wù)特性（剛性事務(wù)）

A(Atomicity)：原子性
C(Consistency)：一致性
I(Isolation)：隔離性
D(Durability)：持久性

1.2事務(wù)形式

編程式：
使用 TransactionTemplate 或者直接使用底層的 TransactionManager 來操作事務(wù) commit 或者 rollback奠骄。
聲明式：
建立在 AOP 基礎(chǔ)上，通過對(duì)方法前后進(jìn)行攔截，加入編程式事務(wù)里的流程控制邏輯样傍。使用的時(shí)候只需要在方法前面加上@Transactional 注解

2.分布式事務(wù)

2.1 概念

就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務(wù)器上沼头，且屬于不同的應(yīng)用阶冈。在這種環(huán)境中，我們之前說過數(shù)據(jù)庫的 ACID 四大特性线椰，已經(jīng)無法滿足我們分布式事務(wù)。

本質(zhì)上來說尘盼，分布式事務(wù)就是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性憨愉。

2.2 CAP理論

一致性(Consistency)、可用性(Availability)卿捎、分區(qū)容錯(cuò)性(Partition tolerance)配紫。

在一個(gè)分布式系統(tǒng)中，最多只能滿足 C午阵、A躺孝、P 中的兩個(gè)，不可能三個(gè)同時(shí)滿足底桂。

分布式系統(tǒng)中植袍，網(wǎng)絡(luò)無法 100% 可靠，分區(qū)(P)其實(shí)是一個(gè)必然現(xiàn)象籽懦。
任何橫向擴(kuò)展策略都要依賴于數(shù)據(jù)分區(qū)于个。因此，設(shè)計(jì)人員必須在一致性(CP)與可用性(AP)之間做出選擇暮顺。

2.3 BASE理論

往往在分布式系統(tǒng)中無法實(shí)現(xiàn)完全一致性厅篓，于是有了 BASE 理論秀存，它是對(duì) CAP 定律的進(jìn)一步擴(kuò)充

Basically Available(基本可用) : 分布式系統(tǒng)在出現(xiàn)故障時(shí)，允許損失部分可用功能羽氮，保證核心功能可用
Soft state(軟狀態(tài)) : 允許系統(tǒng)中存在中間狀態(tài)或链，這個(gè)狀態(tài)不影響系統(tǒng)可用性
Eventually consistent(最終一致性) : 經(jīng)過一段時(shí)間后，所有節(jié)點(diǎn)數(shù)據(jù)都將會(huì)達(dá)到一致

BASE和ACID對(duì)比：
BASE 和 ACID 是相反的档押，它完全不同于 ACID 的強(qiáng)一致性模型澳盐，而是通過犧牲強(qiáng)一致性來獲得可用性，并允許數(shù)據(jù)在一段時(shí)間內(nèi)是不一致的汇荐，但最終達(dá)到一致狀態(tài)洞就。

2.4 2PC

流程圖

image.png

第一階段：
每個(gè)請(qǐng)求發(fā)出預(yù)備提交請(qǐng)求，并作出相應(yīng)的應(yīng)答掀淘，如果都成功旬蟋，進(jìn)行第二階段。
第二階段：
每個(gè)請(qǐng)求發(fā)出提交請(qǐng)求革娄，并作出相應(yīng)應(yīng)答倾贰，如果成功，代表commit完成拦惋，有一個(gè)不成功匆浙，回滾。

優(yōu)點(diǎn)：
盡量保證了數(shù)據(jù)的強(qiáng)一致厕妖，實(shí)現(xiàn)成本較低首尼，在各大主流數(shù)據(jù)庫都有自己實(shí)現(xiàn)，對(duì)于 MySQL 是從 5.5 開始支持言秸。

缺點(diǎn)：

單點(diǎn)問題 : 事務(wù)管理器在整個(gè)流程中扮演的角色很關(guān)鍵软能，如果其宕機(jī)，比如在第一階段已經(jīng)完成举畸，在第二階段正準(zhǔn)備提交的時(shí)候事務(wù)管理器宕機(jī)查排，資源管理器就會(huì)一直阻塞，導(dǎo)致數(shù)據(jù)庫無法使用抄沮。

同步阻塞 : 在準(zhǔn)備就緒之后跋核，資源管理器中的資源一直處于阻塞，直到提交完成叛买，釋放資源砂代。

數(shù)據(jù)不一致 : 兩階段提交協(xié)議雖然為分布式數(shù)據(jù)強(qiáng)一致性所設(shè)計(jì)，但仍然存在數(shù)據(jù)不一致性的可能率挣。
比如在第二階段中泊藕，假設(shè)協(xié)調(diào)者發(fā)出了事務(wù) Commit 的通知，但是因?yàn)榫W(wǎng)絡(luò)問題該通知僅被一部分參與者所收到并執(zhí)行了 Commit 操作，其余的參與者則因?yàn)闆]有收到通知一直處于阻塞狀態(tài)娃圆，這時(shí)候就產(chǎn)生了數(shù)據(jù)的不一致性。

兩階段提交方案鎖定資源時(shí)間長蛾茉，對(duì)性能影響很大讼呢，基本不適合解決微服務(wù)事務(wù)問題。

2.5 3PC

2PC改進(jìn)版本谦炬，將事務(wù)的提交過程分為CanCommit悦屏、PreCommit、do Commit三個(gè)階段來進(jìn)行處理

image.png

第一階段CanCommit（這一階段主要是確定分布式事務(wù)的參與者是否具備了完成 commit 的條件键思，并不會(huì)執(zhí)行事務(wù)操作）
詢問是否可以提交事務(wù)CanCommit础爬，如果可以反饋YES，否則反饋NO吼鳞。

第二階段PreCommit
1.當(dāng)所有參與者均反饋YES看蚜，即執(zhí)行事務(wù)預(yù)提交（PreCommit）
2.任何一個(gè)參與者反饋NO，或者等待超時(shí)后協(xié)調(diào)者尚無法收到所有參與者的反饋赔桌，即中斷事務(wù)供炎。

第三階段do Commit
1.所有參與者均反饋Ack響應(yīng)，即執(zhí)行真正的事務(wù)提交
2.任何一個(gè)參與者反饋NO疾党，或者等待超時(shí)后協(xié)調(diào)者尚無法收到所有參與者的反饋音诫，即中斷事務(wù)

3PC對(duì)比2PC:
注意:在階段三，可能會(huì)出現(xiàn) 2 種故障:協(xié)調(diào)者出現(xiàn)問題/協(xié)調(diào)者和參與者之間的網(wǎng)絡(luò)故障,一段出現(xiàn)了任一一種情況雪位，最終都會(huì)導(dǎo)致參與者無法收到 doCommit 請(qǐng)求或者 abort 請(qǐng)求竭钝，針對(duì)這種情況，參與者都會(huì)在等待超時(shí)之后雹洗，繼續(xù)進(jìn)行事務(wù)提交香罐。
優(yōu)點(diǎn)：
最大的優(yōu)點(diǎn)是減少了參與者的阻塞范圍(第一個(gè)階段是不阻塞的)，能夠在單點(diǎn)故障后繼續(xù)達(dá)成一致(2PC 在提交階段會(huì)出現(xiàn)此問題队伟，而 3PC 會(huì)根據(jù)協(xié)調(diào)者的狀態(tài)進(jìn)行回滾或者提交)穴吹。
缺點(diǎn)：
如果參與者收到了 preCommit 消息后，出現(xiàn)了網(wǎng)絡(luò)分區(qū)嗜侮，那么參與者等待超時(shí)后港令，都會(huì)進(jìn)行事務(wù)的提交，這必然會(huì)出現(xiàn)事務(wù)不一致的問題

2.6 TCC

TCC 其實(shí)就是采用的補(bǔ)償機(jī)制锈颗，其 核心思想 是:
針對(duì)每個(gè)操作顷霹，都要注冊(cè)一個(gè)與其業(yè)務(wù)邏輯對(duì)應(yīng)的確認(rèn)和補(bǔ)償(撤銷)操作。其將整個(gè)業(yè)務(wù)邏輯的每個(gè)分支顯式的分成了 Try击吱、Confirm淋淀、Cancel 三個(gè)操作。

Try 部分完成業(yè)務(wù)的準(zhǔn)備工作
confirm 部分完成業(yè)務(wù)的提交
cancel 部分完成事務(wù)的回滾

image.png

優(yōu)點(diǎn):
跟 2PC 比起來覆醇，實(shí)現(xiàn)以及流程相對(duì)簡單了一些朵纷，但數(shù)據(jù)的一致性比 2PC 也要差一些
缺點(diǎn):
TCC 屬于 應(yīng)用層 的一種補(bǔ)償方式炭臭，所以需要程序員在實(shí)現(xiàn)的時(shí)候多寫很多補(bǔ)償?shù)拇a，而且補(bǔ)償?shù)臅r(shí)候也有可能失敗袍辞，在一些場(chǎng)景中鞋仍，一些業(yè)務(wù)流程可能用 TCC 不太好定義及處理。

3.分布式事務(wù)框架

3.1 LCN

LCN 并不生產(chǎn)事務(wù)搅吁，LCN 只是本地事務(wù)的協(xié)調(diào)工
TX-LCN 定位于一款事務(wù)協(xié)調(diào)性框架威创，框架其本身并不操作事務(wù)，而是基于對(duì)事務(wù)的協(xié)調(diào)從而達(dá)到事務(wù)一致性的效果

原理：
TX-LCN 由兩大模塊組成： TxClient谎懦、TxManager
原理流程圖：

image.png

1.創(chuàng)建事務(wù)組
是指在事務(wù)發(fā)起方開始執(zhí)行業(yè)務(wù)代碼之前先調(diào)用 TxManager 創(chuàng)建事務(wù)組對(duì)象肚豺，然后拿到事務(wù)標(biāo)示 GroupId 的過程。
2.加入事務(wù)組
添加事務(wù)組是指參與方在執(zhí)行完業(yè)務(wù)方法以后界拦，將該模塊的事務(wù)信息通知給 TxManager 的操作吸申。
3.通知事務(wù)組
是指在發(fā)起方執(zhí)行完業(yè)務(wù)代碼以后，將發(fā)起方執(zhí)行結(jié)果狀態(tài)通知給 TxManager,TxManager 將根據(jù)事務(wù)最終狀態(tài)和事務(wù)組的信息來通知相應(yīng)的參與模塊提交或回滾事務(wù)寞奸，并返回結(jié)果給事務(wù)發(fā)起方呛谜。