分布式事務(wù)的概念理論

事務(wù)

具備以下四個(gè)基本特性（ACID）

• 原子性（Atomicity）：一系列操作作被看作一個(gè)整體，要么全部成功，要么全部失敗

• 一致性（consistency）：如果把所有參與者的數(shù)據(jù)看成是一個(gè)數(shù)據(jù)集俱病，那么操作前后，數(shù)據(jù)的總量是不增不減的叠萍。也可以理解成數(shù)據(jù)是滿足完整約束的吼过。舉例：一個(gè)數(shù)據(jù)集中只有兩個(gè)參與者A&B，A持有100元坛掠，B持有0元赊锚，總額100元；A對(duì)B轉(zhuǎn)賬50元屉栓，余額50舷蒲，B收到50，余額50友多，金額總量仍然是100牲平，這就是一致性

• 隔離性（Isolation）：事務(wù)內(nèi)部的數(shù)據(jù)對(duì)其它事務(wù)是不可見(jiàn)的，這也是對(duì)原子性的補(bǔ)充域滥。原子性把系列操作看作一個(gè)操作纵柿，那么內(nèi)部操作是不可見(jiàn)的

• 持久性（Durability）：一個(gè)事務(wù)完成之后數(shù)據(jù)被永遠(yuǎn)保存下來(lái)，其它操作和故障都不會(huì)對(duì)事務(wù)的結(jié)果產(chǎn)生影響

分布式事務(wù)

分布式事務(wù)是指事務(wù)的參與者启绰，支持事務(wù)的服務(wù)器昂儒，資源服務(wù)器以及事務(wù)管理器分別位于不同的系統(tǒng)之中

也就是說(shuō)，需要在不同的數(shù)據(jù)庫(kù)之間實(shí)現(xiàn)事務(wù)

帶來(lái)的挑戰(zhàn)：

1. 多個(gè)子系統(tǒng)獨(dú)立委可，那么多個(gè)子系統(tǒng)所構(gòu)成的大系統(tǒng)渊跋，導(dǎo)致了大系統(tǒng)的管理者也就是事務(wù)協(xié)調(diào)器外置，增加了一致性的難度

2. 網(wǎng)絡(luò)的不穩(wěn)定性

一致性的劃分

• 強(qiáng)一致性：任何一次讀都能都到最新的數(shù)據(jù)，系統(tǒng)中的所有參與者拾酝，看到的操作順序燕少，都和全局時(shí)鐘下的順序一致。簡(jiǎn)而言之微宝，在任意時(shí)刻棺亭，所有節(jié)點(diǎn)中的數(shù)據(jù)是一致的

• 弱一致性：數(shù)據(jù)更新后虎眨，如果能容忍后續(xù)的訪問(wèn)只能訪問(wèn)到部分或者全部訪問(wèn)不到蟋软，則是弱一致性

• 最終一致性：不保證在任意時(shí)刻任意節(jié)點(diǎn)上的同一份數(shù)據(jù)都是相同的，但是隨著事件的遷移嗽桩，不同節(jié)點(diǎn)上的同一份數(shù)據(jù)總是在向趨同的方向變化岳守。簡(jiǎn)單說(shuō)，就是在一段時(shí)間后碌冶，節(jié)點(diǎn)間的數(shù)據(jù)會(huì)最終達(dá)到一致性

弱一致性和最終一致性比較容易混淆湿痢，比較下區(qū)別：

弱一致性，指的是數(shù)據(jù)更新后扑庞，其它參與者并不會(huì)馬上訪問(wèn)到譬重，訪問(wèn)到的是歷史數(shù)據(jù)，但是從訪問(wèn)的時(shí)間線來(lái)看罐氨，每次訪問(wèn)到的結(jié)果都是順序的臀规，所以也叫順序一致性

最終一致性，指的是在一定的時(shí)間之后栅隐，訪問(wèn)到的結(jié)果是一樣的塔嬉，假如中間經(jīng)過(guò)了N次操作，但是可能先訪問(wèn)到了之后的操作結(jié)果租悄，然后再訪問(wèn)到之前的操作谨究，但是經(jīng)過(guò)一定的時(shí)間之后，訪問(wèn)到的數(shù)據(jù)是最新的

從這點(diǎn)來(lái)看泣棋，InnoDB實(shí)現(xiàn)的可重復(fù)讀隔離級(jí)別就是弱一致性胶哲，通過(guò)MVCC實(shí)現(xiàn)快照讀，讀取到的不是最新數(shù)據(jù)潭辈，而是歷史的某個(gè)快照

Zookeeper實(shí)現(xiàn)的zab協(xié)議鸯屿，因?yàn)樵试S半數(shù)節(jié)點(diǎn)成功則提交，那么連接點(diǎn)失敗節(jié)點(diǎn)的客戶端讀取到的也是歷史數(shù)據(jù)萎胰，所以也叫順序一致性

CAP原則

CAP分別指 Consistency(一致性)碾盟，Avaliabity（可用性），Partition tolerance(分區(qū)容錯(cuò)性)

CAP原則的內(nèi)容是：在一個(gè)分布式系統(tǒng)中技竟，CAP不能同時(shí)滿足

另外冰肴，這里的一致性指的是，在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時(shí)刻是否相同熙尉，也就是強(qiáng)一致性

CAP中联逻，主要是C和A不能同時(shí)滿足，即不能滿足強(qiáng)一致性的情況下检痰，還能滿足可用性

證明CA不能同時(shí)滿足

數(shù)據(jù)同步過(guò)程中包归，出現(xiàn)了網(wǎng)絡(luò)無(wú)法訪問(wèn)，或者宕機(jī)的情況

此時(shí)只有兩種方式： 要么阻塞等待網(wǎng)絡(luò)或服務(wù)恢復(fù)之后铅歼，再同步公壤，保證一致性

要么允許客戶端訪問(wèn)到歷史數(shù)據(jù)，保證可用性

BASE理論

BASE理論指的是基本可用Basically Avaliable,軟狀態(tài)Soft Stat,最終一致性

核心思想是即便無(wú)法做到強(qiáng)一致椎椰，但應(yīng)該采用適合業(yè)務(wù)場(chǎng)景的方式保證最終一致性

比如：銀行轉(zhuǎn)賬厦幅，A向B發(fā)起轉(zhuǎn)賬100元，系統(tǒng)首先凍結(jié)A賬戶100元慨飘，等待B成功收到100元之后确憨，再將凍結(jié)金額扣除

銀行轉(zhuǎn)賬的雙方，都能接受數(shù)據(jù)的延遲瓤的，這就是適合業(yè)務(wù)場(chǎng)景的方式

分布式事務(wù)解決方案的理論模型

XA協(xié)議包含：

• 兩階段提交2PC

• 三階段提交3PC

3PC在2PC的基礎(chǔ)上增加了一個(gè)詢問(wèn)階段和超時(shí)機(jī)制休弃，避免資源被永久鎖定，但仍然存在宕機(jī)的問(wèn)題圈膏，導(dǎo)致數(shù)據(jù)不一致塔猾，因此3PC所做的工作有點(diǎn)多余

兩階段XA

2PC的執(zhí)行分為兩個(gè)步驟：

1. Prepare:事務(wù)管理器向所有本地資源管理器發(fā)起請(qǐng)求，詢問(wèn)是否是ready狀態(tài)本辐，所有事務(wù)都將事務(wù)能否成功的信息反饋給協(xié)調(diào)者桥帆，鎖住對(duì)應(yīng)的資源

2. Commit:事務(wù)管理器根據(jù)所有本地資源管理器的反饋，通知所有本地資源管理器慎皱，步調(diào)一致地在所有分支上提交或回滾

因此實(shí)現(xiàn)XA需要有3個(gè)接口老虫，注意，這是在數(shù)據(jù)庫(kù)層面的commit,rollBack

1.prepare接口茫多，鎖定資源

2.commit接口祈匙，提交事務(wù)

3.rollBack接口，回滾事務(wù)

存在的問(wèn)題：

1.prepare鎖住對(duì)用的資源天揖，整個(gè)過(guò)程時(shí)阻塞的

2.事務(wù)協(xié)調(diào)者發(fā)生宕機(jī)夺欲，導(dǎo)致事務(wù)不一致

TCC

TCC理論上也是XA協(xié)議的一種實(shí)現(xiàn)，區(qū)別只是講數(shù)據(jù)庫(kù)層的XA提升到了service層

三個(gè)角色：事務(wù)協(xié)調(diào)者今膊，事務(wù)發(fā)起者些阅，事務(wù)參與者

TCC需要在Service層實(shí)現(xiàn)三個(gè)接口

1. Try階段，鎖定對(duì)應(yīng)的資源

2. Confirm階段斑唬，確認(rèn)市埋，提交資源

3. Cancel階段黎泣，取消，釋放資源

XA總結(jié)

無(wú)論2PC缤谎，3PC還是TCC的理論模型可以看到抒倚，都無(wú)法完全保證事務(wù)的一致性

所以實(shí)際的上解決方案是XA的變種，但還是基于XA的

實(shí)際方案:

• 在事務(wù)協(xié)調(diào)者中維護(hù)一個(gè)大事務(wù)表坷澡，記錄狀態(tài)

• 在事務(wù)協(xié)調(diào)者中維護(hù)一個(gè)小事務(wù)表托呕，記錄每個(gè)事務(wù)參與者的狀態(tài)

• 事務(wù)協(xié)調(diào)者通過(guò)過(guò)定時(shí)檢查大事務(wù)，然后再找到小事務(wù)對(duì)應(yīng)的參與者频敛，通過(guò)調(diào)用XA兩階段的兩階段接口進(jìn)行補(bǔ)償项郊，達(dá)到最終一致

  所以，這也要求兩階段接口具有冪等性

本地消息表

本地消息表方案最初由ebay架構(gòu)師提出姻政，該方案中涉及消息生產(chǎn)者和消息消費(fèi)者兩個(gè)角色

本地消息表.jpg

步驟：

1.A業(yè)務(wù)事務(wù)完成時(shí)呆抑，寫入一條消息到本地消息表岂嗓，記錄消息狀態(tài)是否被成功處理汁展，使用本地事務(wù)保證數(shù)據(jù)一致性，并發(fā)送數(shù)據(jù)到MQ厌殉，如果發(fā)送MQ失敗,則使用定時(shí)任務(wù)掃描補(bǔ)償

2.B業(yè)務(wù)消費(fèi)MQ食绿，并保證消費(fèi)的冪等性，如果消費(fèi)成功公罕，則通知A業(yè)務(wù)更新消息表狀態(tài)（可以是回調(diào)器紧，也可以是MQ）

3.A業(yè)務(wù)根據(jù)通知消息更新消息狀態(tài)

分析：

比較適合的場(chǎng)景是下單成功后，短信的發(fā)送楼眷，郵件的發(fā)送

如果是優(yōu)惠券的發(fā)放铲汪，可能會(huì)出現(xiàn)優(yōu)惠券不足，則可能會(huì)扣減失敗罐柳，如果使用這種方式掌腰，則需要A業(yè)務(wù)設(shè)置一個(gè)中間狀態(tài)，并支持回滾

盡最大努力通知

支付回調(diào)就是典型的盡最大努力通知的場(chǎng)景

第三方支付服務(wù)张吉，如微信齿梁，支付寶，當(dāng)處理完這筆訂單之后肮蛹，就會(huì)發(fā)起一個(gè)回調(diào)通知調(diào)用方

如果失敗會(huì)繼續(xù)重試勺择，直到達(dá)到重試最大次數(shù)，然后交由對(duì)賬系統(tǒng)來(lái)處理

分布式事務(wù)理論模型總結(jié)

從上面的分析可以看到伦忠，不同解決方案的理論模型適合不同的業(yè)務(wù)場(chǎng)景

主要參考：https://xiaomi-info.github.io/2020/01/02/distributed-transaction/