分布式事務(wù)(一)

分布式事務(wù)是個復(fù)雜的問題, 針對不通的業(yè)務(wù)場景, 實現(xiàn)的方式也各式各樣, 今天主要從下面兩個方面:

  1. 為什么? 為什么需要分布式事務(wù);
  2. 怎么做? 分布式事務(wù)如何實現(xiàn);

來展開, 希望這場分享下來, 大家能對分布式事務(wù)有個基礎(chǔ)的了解;

1. 為什么需要分布式事務(wù)?

分布式事務(wù)是伴隨分布式產(chǎn)生的, 我們通過架構(gòu)的演進來看下為什么需要分布式事務(wù);

假設(shè)我們是一家互金公司, 剛開始的時候, 都處于一臺服務(wù)器上: 有個場景是用戶下單購買了基金, 這個時候需要扣賬戶余額, 并給用戶加資產(chǎn);

image.png

當(dāng)所有業(yè)務(wù)都處于一個DB的Connection的時候, 可以使用單機事務(wù)來保證, 落訂單成功了, 必然會給用戶加上資產(chǎn)的;

但是隨著公司的發(fā)展, 單個應(yīng)用已經(jīng)撐不起現(xiàn)有業(yè)務(wù)了, 而且隨著業(yè)務(wù)的擴展, 需要進入為微服務(wù)階段了:

image.png

這只是一個場景: 將原有的系統(tǒng)做了拆分, 有了三個微服務(wù): 訂單, 賬戶和資產(chǎn), 服務(wù)間通過RPC進行信息交互; 這三個微服務(wù)共用同一個DB實例;

還是剛才用戶購買基金, 但是可以看到服務(wù)拆分雖然降低了系統(tǒng)間的耦合, 但是也導(dǎo)致了原本的單機事務(wù)不可用了(這里的不可用指的是跨服務(wù)之間的寫入操作, 單系統(tǒng)內(nèi)仍然可以使用單機事務(wù)), 所以我現(xiàn)在其實是無法保證落訂單成功必定會加資產(chǎn)的;

和單機事務(wù)出現(xiàn)的原因一樣, 正因為出現(xiàn)了三態(tài)問題, 我們就需要引入一種機制, 來幫業(yè)務(wù)系統(tǒng)處理掉中間態(tài);

2. 分布式事務(wù)如何實現(xiàn)

2.1 分布式常見的問題

2.1.1 部分失效問題

當(dāng)一項工作需要多個節(jié)點參與時, 其中的一些節(jié)點可能會失敗, 甚至你不會收到明確的結(jié)果;

2.1.2 不可靠的網(wǎng)絡(luò)

我們的應(yīng)用基本都是互聯(lián)網(wǎng)應(yīng)用, 系統(tǒng)間的交互都是基于網(wǎng)絡(luò)的, 雖然平時在說網(wǎng)絡(luò)調(diào)用時都說的是同步阻塞的, 但是我們所處的網(wǎng)絡(luò)大部分都是異步分組網(wǎng)絡(luò)（asynchronous packet networks）; 也就是說一個節(jié)點給另一個節(jié)點發(fā)送數(shù)據(jù)時, 網(wǎng)絡(luò)不能保證數(shù)據(jù)包什么時候到達, 甚至不能保證一定到達; 可以參考一下場景:

  1. 請求都沒發(fā)出去(被拔網(wǎng)線);
  2. 請求阻塞了, 但是隨后會發(fā)出去;
  3. 請求的遠程節(jié)點可能掛了(斷電或者什么原因);
  4. 遠程節(jié)點收到了, 但是還沒處理(比如在GC), 但是一段時間后會處理;
  5. 遠程節(jié)點響應(yīng)了, 但是在網(wǎng)絡(luò)中丟了(比如交換機配置錯誤, 響應(yīng)到另一臺機器上去了);
  6. 遠程節(jié)點響應(yīng)了, 但是響應(yīng)被阻塞了, 但是恢復(fù)后會發(fā)出;

再回過來看, 如果我們請求方?jīng)]有收到響應(yīng), 是因為

  1. 請求沒發(fā)出?
  2. 遠程節(jié)點不可用?
  3. 遠程節(jié)點掛起了?
  4. 還是遠程節(jié)點響應(yīng)了, 我們沒收到恶阴？

其實我們是不知道遠程階段的狀態(tài)的, 只是知道我們沒有收到響應(yīng);

還有個詞需要專門提一下, 網(wǎng)絡(luò)分區(qū); 簡單來說就是有A, B, C三個節(jié)點, AB能正常通信, 但是AB無法與C通信, 那么就說AB與C形成了網(wǎng)絡(luò)分區(qū);

2.1.3 不可靠的時鐘

2.1.4 拜占庭將軍問題

2.2 CAP

在理論計算機科學(xué)中搅轿，CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer's theorem）旺嬉，它指出對于一個分布式計算系統(tǒng)來說败潦，不可能同時滿足以下三點：[1][2]

  • 一致性（Consistency） （等同于所有節(jié)點訪問同一份最新的數(shù)據(jù)副本）
  • 可用性（Availability）（每次請求都能獲取到非錯的響應(yīng)——但是不保證獲取的數(shù)據(jù)為最新數(shù)據(jù)）
  • 分區(qū)容錯性（Partition tolerance）（以實際效果而言本冲，分區(qū)相當(dāng)于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達成數(shù)據(jù)一致性劫扒，就意味著發(fā)生了分區(qū)的情況檬洞，必須就當(dāng)前操作在C和A之間做出選擇[3]。）

雖然CAP看似給了三個選項, 但這里面的P其實是個必須項, 因為前面也說了, 網(wǎng)絡(luò)是不可靠, 那么就是從C 和 A做取舍, 最終結(jié)果是CP 和 AP;

其實我覺得CAP考慮的還是比較片面的, 主要原因是P只是考慮網(wǎng)絡(luò)異常中的網(wǎng)絡(luò)分區(qū), 延時節(jié)點或者死亡節(jié)點壓根就沒提;

2.2.1 CAP的一致性

這里指的就是線性一致性, 這個線性一致性怎么理解呢? 讀寫并發(fā)的時候, 只有一個讀已經(jīng)讀取了新數(shù)據(jù), 該讀取之后的所有讀取都應(yīng)該讀取的是新數(shù)據(jù);

這里的線性一致性有前提 就是按時間軸, 從左至右不會不會出現(xiàn)回退的情況, 怎么理解:

image.png

注: 此模型不假設(shè)隔離性;

看最后一個讀取 read x = 2是非法的, 因為db1已經(jīng)做了CAS操作, 且最新的X值已經(jīng)被db2讀取到了, 那么db3就不應(yīng)該還能讀取到2了;

所以線性一致性通過記錄所有請求和響應(yīng)的時間, 再校驗他們能否排列成一個時間有序的數(shù)組;

線性一致性 和 可序列化(串行化)

串行化: 指的是事務(wù)并發(fā)的時候, 一個事務(wù)必定在前一個事務(wù)完成以后才會執(zhí)行; 這里事務(wù)執(zhí)行的先后順序可以和事務(wù)實際順序不同;

線性一致性: 線性一致性保證的是讀取和寫入的新鮮度保證, 但是線性一致性不是事務(wù), 所以他不會防止寫入偏差;

2.3 如何實現(xiàn)分布式事務(wù)

2.3.1 回滾型事務(wù): 兩階段提交(2PC)

單機事務(wù)的原子性是由數(shù)據(jù)的落盤順序決定的: 在數(shù)據(jù)最終落盤之前, 事務(wù)都有可能被中止的;

但是分布式事務(wù)涉及到了多個節(jié)點, 那么僅向這些節(jié)點發(fā)送并獨立提交事務(wù)是不可行的, 因為這樣很容易違反原子性: 一些節(jié)點上提交成功了, 但是另一些節(jié)點上提交失敗了; 為了解決這種情況, 必須有一個機制來協(xié)調(diào)這些節(jié)點的事務(wù)提交;

必須要注意一點是:事務(wù)的提交是不可撤銷的, 原因是如果事務(wù)的提交是可撤銷的, 那么該事務(wù)之后的所有寫入都需要被撤銷, 這個是不現(xiàn)實的;

接下來看下2PC是怎么保證原子提交的;

image.png

TC: 事務(wù)協(xié)調(diào)器: 主要作用就是來協(xié)調(diào)各個分支的提交與回滾的; 分布式事務(wù)的原子提交邏輯主要在TC上面;

參與者: 各個系統(tǒng)上的數(shù)據(jù)庫;

主要流程:

  1. 當(dāng)應(yīng)用想要啟動一個分布式事務(wù)時沟饥，它向協(xié)調(diào)者請求一個事務(wù)ID添怔。此事務(wù)ID是全局唯一的。
  2. 應(yīng)用在每個參與者上啟動單節(jié)點事務(wù)贤旷，并在單節(jié)點事務(wù)上捎帶上這個全局事務(wù)ID广料。所有的讀寫都是在這些單節(jié)點事務(wù)中各自完成的。如果在這個階段出現(xiàn)任何問題（例如幼驶，節(jié)點崩潰或請求超時）艾杏，則協(xié)調(diào)者或任何參與者都可以中止。
  3. 當(dāng)應(yīng)用準(zhǔn)備提交時盅藻，協(xié)調(diào)者向所有參與者發(fā)送一個準(zhǔn)備請求购桑，并打上全局事務(wù)ID的標(biāo)記。如果任意一個請求失敗或超時氏淑，則協(xié)調(diào)者向所有參與者發(fā)送針對該事務(wù)ID的中止請求勃蜘。
  4. 參與者收到準(zhǔn)備請求時，需要確保在任意情況下都的確可以提交事務(wù)假残。這包括將所有事務(wù)數(shù)據(jù)寫入磁盤（出現(xiàn)故障缭贡，電源故障，或硬盤空間不足都不能是稍后拒絕提交的理由）以及檢查是否存在任何沖突或違反約束。通過向協(xié)調(diào)者回答“是”匀归，節(jié)點承諾坑资，只要請求，這個事務(wù)一定可以不出差錯地提交穆端。換句話說袱贮，參與者放棄了中止事務(wù)的權(quán)利，但沒有實際提交体啰。
  5. 當(dāng)協(xié)調(diào)者收到所有準(zhǔn)備請求的答復(fù)時攒巍，會就提交或中止事務(wù)作出明確的決定（只有在所有參與者投贊成票的情況下才會提交）。協(xié)調(diào)者必須把這個決定寫到磁盤上的事務(wù)日志中荒勇，如果它隨后就崩潰柒莉，恢復(fù)后也能知道自己所做的決定。這被稱為提交點（commit point）沽翔。
  6. 一旦協(xié)調(diào)者的決定落盤兢孝，提交或放棄請求會發(fā)送給所有參與者。如果這個請求失敗或超時仅偎，協(xié)調(diào)者必須永遠保持重試跨蟹，直到成功為止。沒有回頭路：如果已經(jīng)做出決定橘沥，不管需要多少次重試它都必須被執(zhí)行窗轩。如果參與者在此期間崩潰，事務(wù)將在其恢復(fù)后提交——由于參與者投了贊成座咆，因此恢復(fù)后它不能拒絕提交痢艺。

上面是只有TC的情況, 可以發(fā)現(xiàn)TC的業(yè)務(wù)其實非常重的, 那么在生產(chǎn)中一般會抽象出一個TM(事務(wù)管理器), TM主要是用來定義事務(wù)邊界和事務(wù)編排的, 一般事務(wù)的發(fā)起者就是TM; 下面看一下具有TM的2PC是怎么做的:

image.png

2PC根據(jù)CAP來看的話, 是屬于CP的, 也就是為了一致性犧牲了可用性;

2PC的問題

  1. 2PC要求所有參與者在全局事務(wù)提交之前, 各個分支事務(wù)的資源都必須鎖住; 那么如果一階段完成到全局事務(wù)提交之前, 各個參與者鎖住的資源其實不可用的; 這個時候如果其中某個參與延遲特別高, 就會導(dǎo)致全局事務(wù)變成長事務(wù), 其他參與者的資源長時間處于不可用的狀態(tài);
  2. 2PC的協(xié)調(diào)者如果不做高可用的話, 協(xié)調(diào)者掛了, 所有參與者都只能被動的等待協(xié)調(diào)者重啟, 在這段時間內(nèi), 鎖住的資源同樣得不到釋放;

2.3.2 補償型事務(wù)

2.3.2.1 TCC

在回滾型事務(wù)不理想的情況下, 我們的想法是想讓一階段結(jié)束, 就讓參與者釋放鎖; 然而因為事務(wù)是不可撤銷的, 那么如果參與者出現(xiàn)了異常怎么處理; 我們就需要引入補償, 二階段的時候再起一個事務(wù), 對一階段的操作補償;

補償型事務(wù)中人氣最高的是TCC, TCC是try, confirm, cancel的簡寫; 下面我們來看看TCC是怎么實現(xiàn)分布式事務(wù)的:

image.png

如果只是看圖的話, 和回滾型的2PC基本沒啥區(qū)別的, 但是TCC和2PC最大的區(qū)別是鎖的粒度, TCC把二階段的鎖控制交給了業(yè)務(wù)層來做處理, 分布式事務(wù)隨著一階段的提交, 也就釋放了鎖; 因此使用TCC需要對業(yè)務(wù)做改造, 下面基于基金的購買來說明下如何做業(yè)務(wù)改造;

首先看account的改造:

假設(shè)原本的表結(jié)構(gòu)是:

account_no user_id amount
賬戶 用戶ID 可用金額

那么需要在該表中引入一個中間態(tài)的金額: 凍結(jié)金額

account_no user_id amount frozen_amount
賬戶 用戶ID 可用金額 凍結(jié)金額

同樣position中也需要引入兩個中間態(tài): 一個是購買中的金額, 另一個是贖回中的金額;

position_id user_id capital buying_capital taking_capital
資產(chǎn)ID 用戶ID 持有中的資產(chǎn) 購買中的資產(chǎn) 贖回中的資產(chǎn)

表結(jié)構(gòu)改造完成以后, 結(jié)合圖片來看下TCC是具體怎么執(zhí)行的;

a. TM會開啟全局事務(wù), 獲取全局事務(wù)ID;

b. TM調(diào)用各個分支事務(wù)的分支事務(wù)的try方法:

order_try: insert order status = 0(初始化狀態(tài), 表示處理中);

account_try: update account set amount = amount -100, frozen_amount = frozen_amount + 100;

position_try: update position set buying_capital = buying_capital + 100;

c. TM 等待各個分支事務(wù)的ACK;

d. 如果各個分支事務(wù)try的ACK都是OK, 那么就需要發(fā)送commit指令給TC做全局事務(wù)的提交;

e. TC調(diào)用分支事務(wù)的confirm方法:

order_confirm: update order set status = 1(成功) where id = 1;

account_confirm: udpate account set frozen_amount = frozen_amount - 100;

position_confirm: update position set capital = capital + 100, buying_capital = buying_capital - 100;

f. 如果其中有個分支事務(wù)的ACK是失敗或者超時了, 那么就需要調(diào)用cancel做補償:

g. TC調(diào)用分支事務(wù)的cancel做補償:

order_cancel: update order set status = -1(失敗) where id = 1;

account_cancel: update account set amount = amount + 100, frozen_amount = frozen_amount + 100;

position_cancel: update position set buying_amount = buying_amount - 100;

h. 如果在二階段(confirm | cancel)TC沒有接收到分支事務(wù)二階段的ACK, 是需要再次調(diào)用confirm ｜ cancel方法的, 所以TCC中的confirm ｜ cancel方法一定要是冪等的;

TCC存在的問題

雖然TCC通過將一個全局事務(wù)拆分為兩個小事務(wù), 一階段 和 二階段的事務(wù), 靈活性和可用性得到了保證; 但是剛才的講解中也可以看到, TCC對業(yè)務(wù)的侵入性很高:

  1. 需要提供三個接口, try, confirm, cancel;
  2. 需要對現(xiàn)有業(yè)務(wù)做改造, 需要處理一階段造成的中間態(tài)數(shù)據(jù);
  3. 如果是不可控的第三方業(yè)務(wù), TCC是無法做的(不可能去推動第三方做TCC改造);

那么又沒有即不需要做業(yè)務(wù)改造, 又能避免2PC的性能問題的呢? SAGA可能是一個解決方案;

2.3.2.2 SAGA

SAGA的解決方案其實和TCC挺相似的, 也是將長事務(wù)拆分; 但是SAGA的一階段不是預(yù)留資源, 而是和2PC一樣直接修改并提交; 如果在某個分支事務(wù)執(zhí)行出錯了, 需要按順序回滾之前的所有分支事務(wù), 按順序怎么理解呢? 還是剛才的例子:

order -> account -> position; 結(jié)果在position加資產(chǎn)的時候出異常了, 那么SAGA會進行回滾, 順序是:

account -> order; 也就是回滾的順序是倒序;

雖然SAGA相對TCC省去了業(yè)務(wù)改造, 并且也省去了prepare階段的資源占有; 但是這種直接操作的結(jié)果是對其他業(yè)務(wù)線程可見的, 就會導(dǎo)致充值場景下, 一階段給用戶加了資金, 但是二階段需要回滾, 但是用戶已經(jīng)消費了, 導(dǎo)致回滾失敗的情況;

2.3.3 通知型事務(wù)

通知型事務(wù)的產(chǎn)生是為了解決2PC的性能問題, TCC的業(yè)務(wù)侵入性, 將事務(wù)看成消息, 由消費者來保證最終一致性;

通知型事務(wù)又可以分為可靠通知和最大努力通知;

2.3.3.1 最大努力通知

最大努力通知有個前提就是服務(wù)存在上下游關(guān)系, 上游(provider)成功了, 通知的消費者必須保證消費成功, 如果消費失敗會重試機制; 如果還是重試失敗, 上游必須提供個接口給下游查詢事務(wù)成功后數(shù)據(jù);

這個場景比較常用的是跨系統(tǒng)間的信息交互, 比如支付網(wǎng)關(guān)和業(yè)務(wù)系統(tǒng); 支付網(wǎng)關(guān)支付成功后會通知業(yè)務(wù)系統(tǒng), 業(yè)務(wù)系統(tǒng)消費失敗達到次數(shù)限制后會反查支付網(wǎng)管的數(shù)據(jù);

2.3.3.2 可靠通知

可靠通知可以看成是支持回滾的最大努力通知, 在達到重試次數(shù)后, 允許下游執(zhí)行事務(wù)回滾; 這樣就沒有了消費者必須成功的約束了;

我們回看分布式事務(wù)下的ACID保證，原子性（Atomicity）和持久性（Durability）與傳統(tǒng)事務(wù)無異介陶，但一致性（Consistency）與隔離性（Isolation）上除了2PC完全滿足外, 其他的補償型與通知型事務(wù)都有或多或少的缺失堤舒，它們都強調(diào)最終一致性，即允許在一段可接受的時間內(nèi)各節(jié)點數(shù)據(jù)不一致哺呜，由于它們多半是將大事務(wù)分解成一個個本地小事務(wù)舌缤，所以在一段時間也存在隔離性問題;

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市弦牡，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌漂羊，老刑警劉巖驾锰，帶你破解...
    沈念sama閱讀 218,525評論 6贊 507
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異走越，居然都是意外死亡椭豫，警方通過查閱死者的電腦和手機，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,203評論 3贊 395
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來赏酥，“玉大人喳整，你說我怎么就攤上這事÷惴觯” “怎么了框都？”我有些...
    開封第一講書人閱讀 164,862評論 0贊 354
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長呵晨。 經(jīng)常有香客問我魏保，道長，這世上最難降的妖魔是什么摸屠？ 我笑而不...
    開封第一講書人閱讀 58,728評論 1贊 294
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任谓罗，我火速辦了婚禮，結(jié)果婚禮上季二，老公的妹妹穿的比我還像新娘檩咱。我一直安慰自己，他們只是感情好胯舷，可當(dāng)我...
    茶點故事閱讀 67,743評論 6贊 392
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布刻蚯。 她就那樣靜靜地躺著，像睡著了一般需纳。 火紅的嫁衣襯著肌膚如雪芦倒。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 51,590評論 1贊 305
  • 城市分裂傳說
    那天不翩，我揣著相機與錄音兵扬，去河邊找鬼。 笑死口蝠，一個胖子當(dāng)著我的面吹牛器钟，可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播妙蔗，決...
    沈念sama閱讀 40,330評論 3贊 418
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼傲霸，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了眉反？” 一聲冷哼從身側(cè)響起昙啄，我...
    開封第一講書人閱讀 39,244評論 0贊 276
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎寸五，沒想到半個月后梳凛，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 45,693評論 1贊 314
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡梳杏，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,885評論 3贊 336
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年韧拒，在試婚紗的時候發(fā)現(xiàn)自己被綠了淹接。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,001評論 1贊 348
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡叛溢，死狀恐怖塑悼，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情楷掉，我是刑警寧澤厢蒜，帶...
    沈念sama閱讀 35,723評論 5贊 346
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站靖诗，受9級特大地震影響郭怪，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜刊橘，卻給世界環(huán)境...
    茶點故事閱讀 41,343評論 3贊 330
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一鄙才、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧促绵，春花似錦攒庵、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,919評論 0贊 22
  • 一樁弒父案浓冒，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至尖坤，卻和暖如春稳懒，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背慢味。 一陣腳步聲響...
    開封第一講書人閱讀 33,042評論 1贊 270
  • 情欲美人皮
    我被黑心中介騙來泰國打工场梆， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人纯路。 一個月前我還...
    沈念sama閱讀 48,191評論 3贊 370
  • 代替公主和親
    正文 我出身青樓或油，卻偏偏與公主長得像，于是被迫代替她去往敵國和親驰唬。 傳聞我的和親對象是個殘疾皇子顶岸，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 44,955評論 2贊 355