2 分布式事務(wù)

2.1 問(wèn)題描述

用戶支付完成會(huì)將支付狀態(tài)及訂單狀態(tài)保存在訂單數(shù)據(jù)庫(kù)中，由訂單服務(wù)去維護(hù)訂單數(shù)據(jù)庫(kù)。而學(xué)生選課信息在學(xué) 習(xí)中心數(shù)據(jù)庫(kù)，由學(xué)習(xí)服務(wù)去維護(hù)學(xué)習(xí)中心數(shù)據(jù)庫(kù)的信息。下圖是系統(tǒng)結(jié)構(gòu)圖：

如何實(shí)現(xiàn)兩個(gè)分布式服務(wù)（訂單服務(wù)、學(xué)習(xí)服務(wù)）共同完成一件事即訂單支付成功自動(dòng)添加學(xué)生選課的需求，這里 的關(guān)鍵是如何保證兩個(gè)分布式服務(wù)的事務(wù)的一致性。

嘗試解決上邊的需求，在訂單服務(wù)中遠(yuǎn)程調(diào)用選課接口，偽代碼如下：

訂單支付結(jié)果通知方法｛ 更新支付表中支付狀態(tài)為“成功”。 遠(yuǎn)程調(diào)用選課接口添加選課記錄。 ｝

上邊的邏輯說(shuō)明：

更新支付表狀態(tài)為本地?cái)?shù)據(jù)庫(kù)操作。

遠(yuǎn)程調(diào)用選課接口為網(wǎng)絡(luò)遠(yuǎn)程調(diào)用請(qǐng)求。

為保存事務(wù)上邊兩步操作由spring控制事務(wù)，當(dāng)遇到Exception異常則回滾本地?cái)?shù)據(jù)庫(kù)操作。

問(wèn)題如下：

如果更新支付表失敗則拋出異常，不再執(zhí)行遠(yuǎn)程調(diào)用，此設(shè)想沒(méi)有問(wèn)題。

如果更新支付表成功，網(wǎng)絡(luò)遠(yuǎn)程調(diào)用超時(shí)會(huì)拉長(zhǎng)本地?cái)?shù)據(jù)庫(kù)事務(wù)時(shí)間，影響數(shù)據(jù)庫(kù)性能。

如果更新支付表成功，遠(yuǎn)程調(diào)用添加選課成功（選課數(shù)據(jù)庫(kù)commit成功），最后更新支付表commit失敗，此時(shí)出現(xiàn)操作不一致。

上邊的問(wèn)題涉及到分布式事務(wù)控制。

2.2 什么是分布式事務(wù)

1、什么是分布式系統(tǒng)？
部署在不同結(jié)點(diǎn)上的系統(tǒng)通過(guò)網(wǎng)絡(luò)交互來(lái)完成協(xié)同工作的系統(tǒng)。 比如：充值加積分的業(yè)務(wù)，用戶在充值系統(tǒng)向自己的賬戶充錢，在積分系統(tǒng)中自己積分相應(yīng)的增加。充值系統(tǒng)和積 分系統(tǒng)是兩個(gè)不同的系統(tǒng)，一次充值加積分的業(yè)務(wù)就需要這兩個(gè)系統(tǒng)協(xié)同工作來(lái)完成。

2、什么是事務(wù)？
事務(wù)是指由一組操作組成的一個(gè)工作單元，這個(gè)工作單元具有原子性（atomicity）、一致性（consistency）、隔 離性（isolation）和持久性（durability）。 原子性：執(zhí)行單元中的操作要么全部執(zhí)行成功，要么全部失敗。如果有一部分成功一部分失敗那么成功的操作要全 部回滾到執(zhí)行前的狀態(tài)。 一致性：執(zhí)行一次事務(wù)會(huì)使用數(shù)據(jù)從一個(gè)正確的狀態(tài)轉(zhuǎn)換到另一個(gè)正確的狀態(tài)，執(zhí)行前后 數(shù)據(jù)都是完整的。 隔離性：在該事務(wù)執(zhí)行的過(guò)程中，任何數(shù)據(jù)的改變只存在于該事務(wù)之中，對(duì)外界沒(méi)有影響，事務(wù) 與事務(wù)之間是完全的隔離的。只有事務(wù)提交后其它事務(wù)才可以查詢到最新的數(shù)據(jù)。 持久性：事務(wù)完成后對(duì)數(shù)據(jù)的改 變會(huì)永久性的存儲(chǔ)起來(lái)，即使發(fā)生斷電宕機(jī)數(shù)據(jù)依然在。

3、什么是本地事務(wù)？
本地事務(wù)就是用關(guān)系數(shù)據(jù)庫(kù)來(lái)控制事務(wù)，關(guān)系數(shù)據(jù)庫(kù)通常都具有ACID特性，傳統(tǒng)的單體應(yīng)用通常會(huì)將數(shù)據(jù)全部存儲(chǔ) 在一個(gè)數(shù)據(jù)庫(kù)中，會(huì)借助關(guān)系數(shù)據(jù)庫(kù)來(lái)完成事務(wù)控制。

4、什么是分布式事務(wù)？
在分布式系統(tǒng)中一次操作由多個(gè)系統(tǒng)協(xié)同完成，這種一次事務(wù)操作涉及多個(gè)系統(tǒng)通過(guò)網(wǎng)絡(luò)協(xié)同完成的過(guò)程稱為分布 式事務(wù)。這里強(qiáng)調(diào)的是多個(gè)系統(tǒng)通過(guò)網(wǎng)絡(luò)協(xié)同完成一個(gè)事務(wù)的過(guò)程，并不強(qiáng)調(diào)多個(gè)系統(tǒng)訪問(wèn)了不同的數(shù)據(jù)庫(kù)，即使 多個(gè)系統(tǒng)訪問(wèn)的是同一個(gè)數(shù)據(jù)庫(kù)也是分布式事務(wù)，如下圖：

另外一種分布式事務(wù)的表現(xiàn)是，一個(gè)應(yīng)用程序使用了多個(gè)數(shù)據(jù)源連接了不同的數(shù)據(jù)庫(kù)，當(dāng)一次事務(wù)需要操作多個(gè)數(shù) 據(jù)源，此時(shí)也屬于分布式事務(wù)，當(dāng)系統(tǒng)作了數(shù)據(jù)庫(kù)拆分后會(huì)出現(xiàn)此種情況。

上面兩種分布式事務(wù)表現(xiàn)形式以第一種據(jù)多。

5、分布式事務(wù)有哪些場(chǎng)景？

電商系統(tǒng)中的下單扣庫(kù)存
電商系統(tǒng)中，訂單系統(tǒng)和庫(kù)存系統(tǒng)是兩個(gè)系統(tǒng)，一次下單的操作由兩個(gè)系統(tǒng)協(xié)同完成

2）金融系統(tǒng)中的銀行卡充值
在金融系統(tǒng)中通過(guò)銀行卡向平臺(tái)充值需要通過(guò)銀行系統(tǒng)和金融系統(tǒng)協(xié)同完成。

3）教育系統(tǒng)中下單選課業(yè)務(wù)
在線教育系統(tǒng)中，用戶購(gòu)買課程，下單支付成功后學(xué)生選課成功，此事務(wù)由訂單系統(tǒng)和選課系統(tǒng)協(xié)同完成。

4） SNS系統(tǒng)的消息發(fā)送
在社交系統(tǒng)中發(fā)送站內(nèi)消息同時(shí)發(fā)送手機(jī)短信，一次消息發(fā)送由站內(nèi)消息系統(tǒng)和手機(jī)通信系統(tǒng)協(xié)同完成。

2.3 CAP理論

如何進(jìn)行分布式事務(wù)控制？CAP理論是分布式事務(wù)處理的理論基礎(chǔ)，了解了CAP理論有助于我們研究分布式事務(wù)的 處理方案。

CAP理論是：分布式系統(tǒng)在設(shè)計(jì)時(shí)只能在一致性(Consistency)、可用性(Availability)、分區(qū)容忍性(Partition Tolerance) 中滿足兩種，無(wú)法兼顧三種。

通過(guò)下圖理解CAP理論：

一致性(Consistency)：
服務(wù)A、B、C三個(gè)結(jié)點(diǎn)都存儲(chǔ)了用戶數(shù)據(jù)， 三個(gè)結(jié)點(diǎn)的數(shù)據(jù)需要保持同一時(shí)刻數(shù)據(jù)一致 性。

可用性(Availability)：
服務(wù)A、B、C三個(gè)結(jié)點(diǎn)，其中一個(gè)結(jié)點(diǎn)宕機(jī)不影響整個(gè)集群對(duì)外提供服務(wù)，如果只有服務(wù)A結(jié) 點(diǎn)，當(dāng)服務(wù)A宕機(jī)整個(gè)系統(tǒng)將無(wú)法提供服務(wù)，增加服務(wù)B、C是為了保證系統(tǒng)的可用性。

分區(qū)容忍性(Partition Tolerance)：
分區(qū)容忍性就是允許系統(tǒng)通過(guò)網(wǎng)絡(luò)協(xié)同工作，分區(qū)容忍性要解決由于網(wǎng)絡(luò)分區(qū) 導(dǎo)致數(shù)據(jù)的不完整及無(wú)法訪問(wèn)等問(wèn)題。

分布式系統(tǒng)不可避免的出現(xiàn)了多個(gè)系統(tǒng)通過(guò)網(wǎng)絡(luò)協(xié)同工作的場(chǎng)景，結(jié)點(diǎn)之間難免會(huì)出現(xiàn)網(wǎng)絡(luò)中斷、網(wǎng)延延遲等現(xiàn) 象，這種現(xiàn)象一旦出現(xiàn)就導(dǎo)致數(shù)據(jù)被分散在不同的結(jié)點(diǎn)上，這就是網(wǎng)絡(luò)分區(qū)。

分布式系統(tǒng)能否兼顧C(jī)、A、P？
在保證分區(qū)容忍性的前提下一致性和可用性無(wú)法兼顧，如果要提高系統(tǒng)的可用性就要增加多個(gè)結(jié)點(diǎn)，如果要保證數(shù) 據(jù)的一致性就要實(shí)現(xiàn)每個(gè)結(jié)點(diǎn)的數(shù)據(jù)一致，結(jié)點(diǎn)越多可用性越好，但是數(shù)據(jù)一致性越差。 所以，在進(jìn)行分布式系統(tǒng)設(shè)計(jì)時(shí)，同時(shí)滿足“一致性”、“可用性”和“分區(qū)容忍性”三者是幾乎不可能的。

CAP有哪些組合方式？
1、CA：放棄分區(qū)容忍性，加強(qiáng)一致性和可用性，關(guān)系數(shù)據(jù)庫(kù)按照CA進(jìn)行設(shè)計(jì)。
2、AP：放棄一致性，加強(qiáng)可用性和分區(qū)容忍性，追求最終一致性，很多NoSQL數(shù)據(jù)庫(kù)按照AP進(jìn)行設(shè)計(jì)。 說(shuō)明：這里放棄一致性是指放棄強(qiáng)一致性，強(qiáng)一致性就是寫入成功立刻要查詢出最新數(shù)據(jù)。追求最終一致性是指允 許暫時(shí)的數(shù)據(jù)不一致，只要最終在用戶接受的時(shí)間內(nèi)數(shù)據(jù) 一致即可。
3、CP：放棄可用性，加強(qiáng)一致性和分區(qū)容忍性，一些強(qiáng)一致性要求的系統(tǒng)按CP進(jìn)行設(shè)計(jì)，比如跨行轉(zhuǎn)賬，一次轉(zhuǎn) 賬請(qǐng)求要等待雙方銀行系統(tǒng)都完成整個(gè)事務(wù)才算完成。

說(shuō)明：由于網(wǎng)絡(luò)問(wèn)題的存在CP系統(tǒng)可能會(huì)出現(xiàn)待等待超時(shí)，如果沒(méi)有處理超時(shí)問(wèn)題則整理系統(tǒng)會(huì)出現(xiàn)阻塞。

在分布式系統(tǒng)設(shè)計(jì)中AP的應(yīng)用較多，即保證分區(qū)容忍性和可用性，犧牲數(shù)據(jù)的強(qiáng)一致性（寫操作后立刻讀取到最 新?lián)?#xff09;，保證數(shù)據(jù)最終一致性。比如：訂單退款，今日退款成功，明日賬戶到賬，只要在預(yù)定的用戶可以接受的 時(shí)間內(nèi)退款事務(wù)走完即可。

2.4 解決方案

2.4.1 兩階段提交協(xié)議(2PC)

為解決分布式系統(tǒng)的數(shù)據(jù)一致性問(wèn)題出現(xiàn)了兩階段提交協(xié)議（2 Phase Commitment Protocol），兩階段提交由 協(xié)調(diào)者和參與者組成，共經(jīng)過(guò)兩個(gè)階段和三個(gè)操作，部分關(guān)系數(shù)據(jù)庫(kù)如Oracle、MySQL支持兩階段提交協(xié)議，本節(jié) 講解關(guān)系數(shù)據(jù)庫(kù)兩階段提交協(xié)議。

參考：
2PC：
https://en.wikipedia.org/wiki/Two-phase_commit_protocol

2PC協(xié)議流程圖：

1）第一階段：準(zhǔn)備階段（prepare）
協(xié)調(diào)者通知參與者準(zhǔn)備提交訂單，參與者開(kāi)始投票。
協(xié)調(diào)者完成準(zhǔn)備工作向協(xié)調(diào)者回應(yīng)Yes。

2）第二階段：提交(commit)/回滾(rollback)階段

協(xié)調(diào)者根據(jù)參與者的投票結(jié)果發(fā)起最終的提交指令。 如果有參與者沒(méi)有準(zhǔn)備好則發(fā)起回滾指令。 一個(gè)下單減庫(kù)存的例子：

應(yīng)用程序連接兩個(gè)數(shù)據(jù)源。

應(yīng)用程序通過(guò)事務(wù)協(xié)調(diào)器向兩個(gè)庫(kù)發(fā)起prepare，兩個(gè)數(shù)據(jù)庫(kù)收到消息分別執(zhí)行本地事務(wù)（記錄日志），但不提交，如果執(zhí)行成功則回復(fù)yes，否則回復(fù)no。

事務(wù)協(xié)調(diào)器收到回復(fù)，只要有一方回復(fù)no則分別向參與者發(fā)起回滾事務(wù)，參與者開(kāi)始回滾事務(wù)。

事務(wù)協(xié)調(diào)器收到回復(fù)，全部回復(fù)yes，此時(shí)向參與者發(fā)起提交事務(wù)。如果參與者有一方提交事務(wù)失敗則由事務(wù)協(xié) 調(diào)器發(fā)起回滾事務(wù)。

2PC的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：
實(shí)現(xiàn)強(qiáng)一致性，部分關(guān)系數(shù)據(jù)庫(kù)支持（Oracle、MySQL等）。
缺點(diǎn)：
整個(gè)事務(wù)的執(zhí)行需要由協(xié)調(diào)者在多個(gè)節(jié)點(diǎn)之間去協(xié)調(diào)，增加了事務(wù)的執(zhí)行時(shí)間，性能低下。 解決方案有:springboot+Atomikos or Bitronix

3PC主要是解決協(xié)調(diào)者與參與者通信阻塞問(wèn)題而產(chǎn)生的，它比2PC傳遞的消息還要多，性能不高。

詳細(xì)參考3PC： https://en.wikipedia.org/wiki/Three-phase_commit_protocol

2.4.2 事務(wù)補(bǔ)償（TCC）

TCC事務(wù)補(bǔ)償是基于2PC實(shí)現(xiàn)的業(yè)務(wù)層事務(wù)控制方案，它是Try、Confirm和Cancel三個(gè)單詞的首字母，含義如下：

Try 檢查及預(yù)留業(yè)務(wù)資源 完成提交事務(wù)前的檢查，并預(yù)留好資源。

Confirm 確定執(zhí)行業(yè)務(wù)操作 對(duì)try階段預(yù)留的資源正式執(zhí)行。

Cancel 取消執(zhí)行業(yè)務(wù)操作 對(duì)try階段預(yù)留的資源釋放。

下邊用一個(gè)下單減庫(kù)存的業(yè)務(wù)為例來(lái)說(shuō)明：

Try 下單業(yè)務(wù)由訂單服務(wù)和庫(kù)存服務(wù)協(xié)同完成，在try階段訂單服務(wù)和庫(kù)存服務(wù)完成檢查和預(yù)留資源。 訂單服務(wù)檢查當(dāng)前是否滿足提交訂單的條件（比如：當(dāng)前存在未完成訂單的不允許提交新訂單）。 庫(kù)存服務(wù)檢查當(dāng)前是否有充足的庫(kù)存，并鎖定資源。

Confirm 訂單服務(wù)和庫(kù)存服務(wù)成功完成Try后開(kāi)始正式執(zhí)行資源操作。 訂單服務(wù)向訂單寫一條訂單信息。 庫(kù)存服務(wù)減去庫(kù)存。

Cancel 如果訂單服務(wù)和庫(kù)存服務(wù)有一方出現(xiàn)失敗則全部取消操作。 訂單服務(wù)需要?jiǎng)h除新增的訂單信息。 庫(kù)存服務(wù)將減去的庫(kù)存再還原。

優(yōu)點(diǎn)：最終保證數(shù)據(jù)的一致性，在業(yè)務(wù)層實(shí)現(xiàn)事務(wù)控制，靈活性好。
缺點(diǎn)：開(kāi)發(fā)成本高，每個(gè)事務(wù)操作每個(gè)參與者都需要實(shí)現(xiàn)try/confirm/cancel三個(gè)接口。

注意：TCC的try/confirm/cancel接口都要實(shí)現(xiàn)冪等性，在為在try、confirm、cancel失敗后要不斷重試。 什么是冪等性？

冪等性是指同一個(gè)操作無(wú)論請(qǐng)求多少次，其結(jié)果都相同。

冪等操作實(shí)現(xiàn)方式有：

操作之前在業(yè)務(wù)方法進(jìn)行判斷如果執(zhí)行過(guò)了就不再執(zhí)行。

緩存所有請(qǐng)求和處理的結(jié)果，已經(jīng)處理的請(qǐng)求則直接返回結(jié)果。

在數(shù)據(jù)庫(kù)表中加一個(gè)狀態(tài)字段（未處理，已處理），數(shù)據(jù)操作時(shí)判斷未處理時(shí)再處理。

2.4.3 消息隊(duì)列實(shí)現(xiàn)最終一致

本方案是將分布式事務(wù)拆分成多個(gè)本地事務(wù)來(lái)完成，并且由消息隊(duì)列異步協(xié)調(diào)完成，如下圖： 下邊以下單減少庫(kù)存為例來(lái)說(shuō)明：

訂單服務(wù)和庫(kù)存服務(wù)完成檢查和預(yù)留資源。

訂單服務(wù)在本地事務(wù)中完成添加訂單表記錄和添加“減少庫(kù)存任務(wù)消息”。

由定時(shí)任務(wù)根據(jù)消息表的記錄發(fā)送給MQ通知庫(kù)存服務(wù)執(zhí)行減庫(kù)存操作。

庫(kù)存服務(wù)執(zhí)行減少庫(kù)存，并且記錄執(zhí)行消息狀態(tài)（為避免重復(fù)執(zhí)行消息，在執(zhí)行減庫(kù)存之前查詢是否執(zhí)行過(guò)此 消息）。

庫(kù)存服務(wù)向MQ發(fā)送完成減少庫(kù)存的消息。

訂單服務(wù)接收到完成庫(kù)存減少的消息后刪除原來(lái)添加的“減少庫(kù)存任務(wù)消息”。

實(shí)現(xiàn)最終事務(wù)一致要求：預(yù)留資源成功理論上要求正式執(zhí)行成功，如果執(zhí)行失敗會(huì)進(jìn)行重試，要求業(yè)務(wù)執(zhí)行方法實(shí) 現(xiàn)冪等。

優(yōu)點(diǎn)：
由MQ按異步的方式協(xié)調(diào)完成事務(wù)，性能較高。 不用實(shí)現(xiàn)try/confirm/cancel接口，開(kāi)發(fā)成本比TCC低。

缺點(diǎn)：
此方式基于關(guān)系數(shù)據(jù)庫(kù)本地事務(wù)來(lái)實(shí)現(xiàn)，會(huì)出現(xiàn)頻繁讀寫數(shù)據(jù)庫(kù)記錄，浪費(fèi)數(shù)據(jù)庫(kù)資源，另外對(duì)于高并發(fā)操作不是 最佳方案。

總結(jié)

以上是生活随笔為你收集整理的CMS-订单系统的分布式事务如何处理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。