啥？分布式啥？啥事務(wù)？

二將軍問題

我們先來看個(gè)故事，相信會(huì)有助于你對(duì)分布式事務(wù)的理解。二將軍問題是一個(gè)計(jì)算機(jī)領(lǐng)域一個(gè)經(jīng)典的問題。

「故事背景」黑白兩軍交戰(zhàn)之際，兩股白軍將黑軍被圍困在山谷之中；山谷兩側(cè)任意一股白軍都比山谷中的黑軍人數(shù)少，因此單獨(dú)一只白軍向黑軍發(fā)起進(jìn)攻，必?cái)o疑，但是兩股白軍人數(shù)總和卻比黑軍人數(shù)多，若能同時(shí)向黑軍發(fā)起進(jìn)攻，則可大勝。而山谷左右側(cè)的白軍相互通信（告知進(jìn)攻時(shí)間）必然會(huì)穿過山谷，但是有被黑軍俘虜?shù)娘L(fēng)險(xiǎn)，如果你是山谷左側(cè)的白軍統(tǒng)帥，你會(huì)如何抉擇呢？

---

「戰(zhàn)況分析」

• 「情形1」:送信失敗，如下圖所示，左側(cè)白軍穿過山谷的時(shí)候被黑軍俘虜了，右側(cè)白軍仍舊不知道左側(cè)白軍的進(jìn)攻信息。

• 「情形2」:送信成功，回信失敗。如下圖所示，左側(cè)白軍穿過山谷將信息成功通知給右側(cè)白軍，但是右側(cè)白軍攜帶"收到命令"的信息，穿過山谷向左側(cè)白軍通知的時(shí)候被黑軍俘虜了，此時(shí)左側(cè)白軍不知道右側(cè)白軍是否接收到進(jìn)攻命令。

• 「情形3」:送信成功，回信成功，如下圖所示，白軍勝利毫無疑問。

---

「戰(zhàn)役復(fù)盤」

1. 面對(duì)不穩(wěn)定的信息傳輸通道(山谷中的黑軍)，要完成兩股白軍的通信是有難度的，送信回信的過程就好比我們系統(tǒng)中Send和Ack 的過程，并且只要送信或者回信任意一次失敗，整個(gè)信息傳遞就標(biāo)志著失敗，無法完成進(jìn)攻，這像不像CAP的最佳打開方式 中提到的原子性，事務(wù)中的每個(gè)操作都成功，事務(wù)才會(huì)提交。
2. 如果真的發(fā)生了情形1和情形2，如果你是左側(cè)白軍的統(tǒng)帥或者右側(cè)白軍的負(fù)責(zé)人，你該怎么辦呢？是不是應(yīng)該等等，看看有沒有回信，如果長時(shí)間沒有回信就認(rèn)為這個(gè)送信的人被俘虜了，再派1個(gè)人重復(fù)送信的過程，這就是我們?cè)谙到y(tǒng)中常見的超時(shí)重試。當(dāng)然重試一定是有限制的，如果真的無限重試。那么左右側(cè)白軍人數(shù)有可能會(huì)清零(資源耗盡)，戰(zhàn)爭自然失敗(系統(tǒng)自然崩潰)
3. 如果左側(cè)白軍派遣多名士兵同時(shí)發(fā)起送信的動(dòng)作，那么對(duì)于右側(cè)白軍來說不管收到多少次信息，都只進(jìn)攻一次。類比咱們系統(tǒng)來說，對(duì)于不管是一次請(qǐng)求還是多次請(qǐng)求，結(jié)果都是一樣的，這就是系統(tǒng)冪等性
4. 這個(gè)二軍問題，像不像TCP鏈接的握手的過程呢？問題來了，為什么是三次握手，而不是兩次握手?文章留言回復(fù)下，如果你不知道可要補(bǔ)課啦

---

 

本地事務(wù)

本地事務(wù)實(shí)際上是指傳統(tǒng)的事務(wù)，也就是大學(xué)課程里數(shù)據(jù)庫原理中的提到事務(wù)。在CAP的最佳打開方式的文章中，我們也可以看到，ACID就是本地事務(wù)的最好詮釋，原子性、一致性、隔離性、持久性，詳細(xì)解釋不再贅述，可以參看CAP篇中的含義。

當(dāng)時(shí)我是用的午休去超市買蘋果來舉例，我們?cè)俸唵沃販叵卤镜厥聞?wù)。當(dāng)我在超市選好蘋果去結(jié)賬的時(shí)候，超市系統(tǒng)突然崩了無法結(jié)賬，雖然選好了蘋果，但也沒啥用，雖然這次買蘋果的事務(wù)自然而然也就失敗了。但是對(duì)于超市來說，所有數(shù)據(jù)都不曾有任何變化，這就是本地事務(wù)。

---

 

分布式事務(wù)

我們沿著本地事務(wù)的思路繼續(xù)深入，這次超市系統(tǒng)崩了的原因是超市發(fā)展很快，數(shù)據(jù)量的不斷增長，導(dǎo)致后端單數(shù)據(jù)庫性能已經(jīng)達(dá)到了瓶頸，于是開始進(jìn)行分庫(分到多個(gè)物理實(shí)例)原來在單庫中會(huì)操作多個(gè)表，由于不涉及網(wǎng)絡(luò)傳輸，直接通過RDBMS的undo log、redo log以及鎖機(jī)制就可以滿足本地事務(wù)的所有需求了，但是分庫后，意味著出現(xiàn)了跨庫、跨網(wǎng)絡(luò)的的事務(wù)場景。

舉個(gè)例子，在分庫前，優(yōu)惠券邏輯使用的表A和支付邏輯相關(guān)的表B在同一個(gè)庫中的，此時(shí)超市有蘋果促銷的活動(dòng)，使用優(yōu)惠券和支付邏輯是在同一個(gè)事務(wù)中，因此在操作支付時(shí)，如果支付失敗，本地事務(wù)會(huì)強(qiáng)制將使用優(yōu)惠券的操作也會(huì)失敗。而由于分庫拆分成兩個(gè)獨(dú)立實(shí)例，也就導(dǎo)致在跨網(wǎng)絡(luò)的情況下，無法將單機(jī)事務(wù)在數(shù)據(jù)資源層面完美支持，因此介于此種情況，自然而然有了分布式事務(wù)的應(yīng)用場景。

---

我們來明確下什么是分布式事務(wù)，通常分布式事務(wù)中存在兩種角色

• 資源管理器（Resource Manager, RM）即事務(wù)參與者
• 事務(wù)管理器（Transaction Manager, TM）即事務(wù)協(xié)調(diào)者

在分布式事務(wù)的模型中，RM對(duì)應(yīng)著資源，一個(gè)DB、一個(gè)被依賴服務(wù)都是一個(gè)RM；而TM 是一個(gè)全局事務(wù)管理器，一個(gè)TM會(huì)管理多個(gè)RM，就類似上面我們的超市促銷支付的邏輯去協(xié)調(diào)多方數(shù)據(jù)庫資源，從而協(xié)調(diào)各個(gè)本地事務(wù)的進(jìn)度，使其共同提交或回滾，最終達(dá)成一種全局的 ACID 特性。

---

 

兩種事務(wù)的區(qū)別

實(shí)際上與分布式系統(tǒng)CAP類似，分布式事務(wù)中涉及到的所有參與者會(huì)分布在同一個(gè)網(wǎng)絡(luò)環(huán)境中，參與者會(huì)通過相互通信達(dá)到分布式系統(tǒng)的一致性，但因?yàn)榫W(wǎng)絡(luò)環(huán)境的不確定性，網(wǎng)絡(luò)不可避免的會(huì)出現(xiàn)超時(shí)、失敗的情況，進(jìn)而可能導(dǎo)致數(shù)據(jù)出現(xiàn)不一致的情況。而本地事務(wù)并不需要多次rpc，自然也就也就不存在分布式一致性問題，分布式一致性的核心點(diǎn)在于數(shù)據(jù)的分布式操作，導(dǎo)致本地事務(wù)無法保證數(shù)據(jù)的原子性。

舉個(gè)實(shí)際的??，我們工作中經(jīng)常會(huì)有獨(dú)立負(fù)責(zé)一個(gè)項(xiàng)目的情況，自己會(huì)了解項(xiàng)目的所有邏輯，不需要和其他人交互。此時(shí)如果項(xiàng)目參與的人數(shù)增加到多個(gè)，成立了一個(gè)項(xiàng)目組，要想順利的繼續(xù)完成項(xiàng)目，就會(huì)導(dǎo)致你經(jīng)常需要和項(xiàng)目組的其他人進(jìn)行交流，保持目標(biāo)/進(jìn)度的一致，此時(shí)這個(gè)項(xiàng)目組就是分布式系統(tǒng)，每一個(gè)項(xiàng)目組成員就是分布式系統(tǒng)中的節(jié)點(diǎn)。由于溝通的不確定性，當(dāng)某個(gè)模塊廢棄時(shí)，除了自己本地修改外，還需要通知所有人修改。這時(shí)如果溝通的不到位，就會(huì)出現(xiàn)不一致的情況。因此在分布式事務(wù)中會(huì)出現(xiàn)一個(gè)全局協(xié)調(diào)者的角色(TM)，協(xié)調(diào)所有資源(RM)步調(diào)，保證全局一致。

 

分布式事務(wù)的場景

• 「資源主導(dǎo)」

上面超市買蘋果的例子僅僅是舉了一個(gè)由于分庫而引發(fā)的分布式事務(wù)場景，我們針對(duì)這個(gè)場景向分布式系統(tǒng)上的延伸，如下圖所示，當(dāng)單點(diǎn)系統(tǒng)進(jìn)行分布式化之后，實(shí)際上是由于資源的多點(diǎn)分布導(dǎo)致分布式事務(wù)場景的產(chǎn)生。

---

• 「服務(wù)依賴主導(dǎo)」

下圖展示的服務(wù)依賴主導(dǎo)，畢竟業(yè)務(wù)架構(gòu)通常是比較復(fù)雜的，只需要一個(gè)服務(wù)訪問一份數(shù)據(jù)資源的服務(wù)還是比較少的，隨著SOA服務(wù)化理念的加深，特別是微服務(wù)的大規(guī)模應(yīng)用，導(dǎo)致服務(wù)依賴非常復(fù)雜，因此這種分布式事務(wù)的場景完全由服務(wù)依賴所主導(dǎo)

---

• 「混合主導(dǎo)」

即數(shù)據(jù)資源分布+服務(wù)依賴主導(dǎo)，這里需要注意的是，不是說傳統(tǒng)數(shù)據(jù)庫和分布式系統(tǒng)就是涇渭分明的，在一個(gè)成熟的業(yè)務(wù)架構(gòu)下，一會(huì)存在DB和分布式系統(tǒng)混用的情況。如下所示

---

 

分布式事務(wù)的分類

分布式事務(wù)從實(shí)現(xiàn)方案的類型上分為「剛性事務(wù)」和「柔性事務(wù)」。

剛性事務(wù)通常并不需要業(yè)務(wù)進(jìn)行改造，實(shí)現(xiàn)的是強(qiáng)一致性，強(qiáng)一致性的同步阻塞導(dǎo)致服務(wù)并發(fā)上不去，比較適合短的事務(wù)。而柔性事務(wù)通常業(yè)務(wù)會(huì)參與進(jìn)行改造，事務(wù)基本都是異步的，因此實(shí)現(xiàn)的是最終一致性，高并發(fā)，比較適合長事務(wù)。

換個(gè)角度看，結(jié)合CAP中的內(nèi)容，剛性事務(wù)對(duì)應(yīng)著分布式系統(tǒng)中遵循ACID的CA系統(tǒng)；柔性事務(wù)對(duì)應(yīng)著分布式系統(tǒng)中遵循BASE的CP系統(tǒng)。

有道無術(shù)，術(shù)可成；有術(shù)無道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??