分布式事務(wù)指事務(wù)的操作位于不同的節(jié)點(diǎn)上，需要保證事務(wù)的 AICD 特性。
例如在下單場(chǎng)景下，庫(kù)存和訂單如果不在同一個(gè)節(jié)點(diǎn)上，就涉及分布式事務(wù)。
在分布式系統(tǒng)中，要實(shí)現(xiàn)分布式事務(wù)，無(wú)外乎那幾種解決方案。
兩階段提交（Two-phase Commit，2PC），通過(guò)引入?yún)f(xié)調(diào)者（Coordinator）來(lái)協(xié)調(diào)參與者的行為，并最終決定這些參與者是否要真正執(zhí)行事務(wù)。1. 運(yùn)行過(guò)程
1.1 準(zhǔn)備階段
協(xié)調(diào)者詢問(wèn)參與者事務(wù)是否執(zhí)行成功，參與者發(fā)回事務(wù)執(zhí)行結(jié)果。1.2 提交階段
如果事務(wù)在每個(gè)參與者上都執(zhí)行成功，事務(wù)協(xié)調(diào)者發(fā)送通知讓參與者提交事務(wù)；否則，協(xié)調(diào)者發(fā)送通知讓參與者回滾事務(wù)。需要注意的是，在準(zhǔn)備階段，參與者執(zhí)行了事務(wù)，但是還未提交。只有在提交階段接收到協(xié)調(diào)者發(fā)來(lái)的通知后，才進(jìn)行提交或者回滾。2. 存在的問(wèn)題
2.3 數(shù)據(jù)不一致 在階段二，如果協(xié)調(diào)者只發(fā)送了部分 Commit 消息，此時(shí)網(wǎng)絡(luò)發(fā)生異常，那么只有部分參與者接收到 Commit 消息，也就是說(shuō)只有部分參與者提交了事務(wù)，使得系統(tǒng)數(shù)據(jù)不一致。
TCC 其實(shí)就是采用的補(bǔ)償機(jī)制，其核心思想是：針對(duì)每個(gè)操作，都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)和補(bǔ)償（撤銷(xiāo)）操作。它分為三個(gè)階段：舉個(gè)例子，假入 Bob 要向 Smith 轉(zhuǎn)賬，思路大概是：我們有一個(gè)本地方法，里面依次調(diào)用- 首先在 Try 階段，要先調(diào)用遠(yuǎn)程接口把 Smith 和 Bob 的錢(qián)給凍結(jié)起來(lái)。
- 在 Confirm 階段，執(zhí)行遠(yuǎn)程調(diào)用的轉(zhuǎn)賬的操作，轉(zhuǎn)賬成功進(jìn)行解凍。
- 如果第2步執(zhí)行成功，那么轉(zhuǎn)賬成功，如果第二步執(zhí)行失敗，則調(diào)用遠(yuǎn)程凍結(jié)接口對(duì)應(yīng)的解凍方法 (Cancel)。
優(yōu)點(diǎn)： 跟2PC比起來(lái)，實(shí)現(xiàn)以及流程相對(duì)簡(jiǎn)單了一些，但數(shù)據(jù)的一致性比2PC也要差一些缺點(diǎn)： 缺點(diǎn)還是比較明顯的，在2,3步中都有可能失敗。TCC屬于應(yīng)用層的一種補(bǔ)償方式，所以需要程序員在實(shí)現(xiàn)的時(shí)候多寫(xiě)很多補(bǔ)償?shù)拇a，在一些場(chǎng)景中，一些業(yè)務(wù)流程可能用TCC不太好定義及處理。本地消息表與業(yè)務(wù)數(shù)據(jù)表處于同一個(gè)數(shù)據(jù)庫(kù)中，這樣就能利用本地事務(wù)來(lái)保證在對(duì)這兩個(gè)表的操作滿足事務(wù)特性，并且使用了消息隊(duì)列來(lái)保證最終一致性。- 在分布式事務(wù)操作的一方完成寫(xiě)業(yè)務(wù)數(shù)據(jù)的操作之后向本地消息表發(fā)送一個(gè)消息，本地事務(wù)能保證這個(gè)消息一定會(huì)被寫(xiě)入本地消息表中。
- 之后將本地消息表中的消息轉(zhuǎn)發(fā)到 Kafka 等消息隊(duì)列中，如果轉(zhuǎn)發(fā)成功則將消息從本地消息表中刪除，否則繼續(xù)重新轉(zhuǎn)發(fā)。
- 在分布式事務(wù)操作的另一方從消息隊(duì)列中讀取一個(gè)消息，并執(zhí)行消息中的操作。
優(yōu)點(diǎn)： 一種非常經(jīng)典的實(shí)現(xiàn)，避免了分布式事務(wù)，實(shí)現(xiàn)了最終一致性。
缺點(diǎn)： 消息表會(huì)耦合到業(yè)務(wù)系統(tǒng)中，如果沒(méi)有封裝好的解決方案，會(huì)有很多雜活需要處理。優(yōu)點(diǎn)： 實(shí)現(xiàn)了最終一致性，不需要依賴(lài)本地?cái)?shù)據(jù)庫(kù)事務(wù)。
缺點(diǎn)： 實(shí)現(xiàn)難度大，主流MQ不支持，RocketMQ事務(wù)消息部分代碼也未開(kāi)源。通過(guò)本文我們總結(jié)并對(duì)比了幾種分布式分解方案的優(yōu)缺點(diǎn)，分布式事務(wù)本身是一個(gè)技術(shù)難題，是沒(méi)有一種完美的方案應(yīng)對(duì)所有場(chǎng)景的，具體還是要根據(jù)業(yè)務(wù)場(chǎng)景去抉擇吧。筆者上家公司是試用阿里RocketMQ去實(shí)現(xiàn)的分布式事務(wù)，現(xiàn)在也有除了很多分布式事務(wù)的協(xié)調(diào)器，比如LCN等，大家可以多去嘗試。
本站僅提供存儲(chǔ)服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)
點(diǎn)擊舉報(bào)。
