點擊上方藍(lán)色字體，選擇“標(biāo)星公眾號”

優(yōu)質(zhì)文章，第一時間送達(dá)

1、事務(wù)的定義

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

本地事務(wù)

    本地事務(wù)就是用關(guān)系數(shù)據(jù)庫來控制事務(wù)， 關(guān)系數(shù)據(jù)庫通常都具有ACID特性， 傳統(tǒng)的單體應(yīng)用通常會將數(shù)據(jù)全部存儲在一個數(shù)據(jù)庫中， 會借助關(guān)系數(shù)據(jù)庫來完成事務(wù)控制。

分布式事務(wù)

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

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

分布式事務(wù)場景

1 ) 電商系統(tǒng)中的下單扣庫存
電商系統(tǒng)中， 訂單系統(tǒng)和庫存系統(tǒng)是兩個系統(tǒng)， 一次下單的操作由兩個系統(tǒng)協(xié)同完成
2） 金融系統(tǒng)中的銀行卡充值
在金融系統(tǒng)中通過銀行卡向平臺充值需要通過銀行系統(tǒng)和金融系統(tǒng)協(xié)同完成。
3） 教育系統(tǒng)中下單選課業(yè)務(wù)
在線教育系統(tǒng)中， 用戶購買課程， 下單支付成功后學(xué)生選課成功， 此事務(wù)由訂單系統(tǒng)和選課系統(tǒng)協(xié)同完成。
4） SNS系統(tǒng)的消息發(fā)送
在社交系統(tǒng)中發(fā)送站內(nèi)消息同時發(fā)送手機(jī)短信， 一次消息發(fā)送由站內(nèi)消息系統(tǒng)和手機(jī)通信系統(tǒng)協(xié)同完成。

2、CAP理論（Base理論可以自行學(xué)習(xí)）

CAP理論是分布式事務(wù)處理的理論基礎(chǔ)。

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

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

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

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

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

CAP組合方式

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

由于網(wǎng)絡(luò)問題的存在CP系統(tǒng)可能會出現(xiàn)待等待超時， 如果沒有處理超時問題則整理系統(tǒng)會出現(xiàn)阻塞。

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

BASE理論：

eBay架構(gòu)師 Dan Pritchett 提出，是CAP理論的延伸，核心思想是即使無法保證強(qiáng)一致性，但是應(yīng)用可以采用某種方式達(dá)到最終一致性。

BASE理論是基本可用（Basically Available）、柔性狀態(tài)（Soft Stat）、最終一致性（Eventually Consistency）。

基本可用：分布式系統(tǒng)在出現(xiàn)故障的時候，允許損失部分可用性，保證核心可用，場景為服務(wù)降級。

柔性狀態(tài)：允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會影響系統(tǒng)整體可用性。分布式存儲中，一份數(shù)據(jù)一般會有三個副本至少，允許不同節(jié)點間副本同步的延時就是柔性狀態(tài)的體現(xiàn)。

最終一致性：系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一段時間之后 ，最終達(dá)到一致的狀態(tài)。

3、分布式事務(wù)解決方案

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

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

1）第一階段：準(zhǔn)備階段（ prepare）協(xié)調(diào)者通知參與者準(zhǔn)備提交訂單， 參與者開始投票。協(xié)調(diào)者完成準(zhǔn)備工作向協(xié)調(diào)者回應(yīng)Yes。
2）第二階段：提交(commit)/回滾(rollback)階段協(xié)調(diào)者根據(jù)參與者的投票結(jié)果發(fā)起最終的提交指令。如果有參與者沒有準(zhǔn)備好則發(fā)起回滾指令。

1 、應(yīng)用程序連接兩個數(shù)據(jù)源。
2、 應(yīng)用程序通過事務(wù)協(xié)調(diào)器向兩個庫發(fā)起prepare， 兩個數(shù)據(jù)庫收到消息分別執(zhí)行本地事務(wù)（ 記錄日志），但不提交， 如果執(zhí)行成功則回復(fù)yes， 否則回復(fù)no。
3、 事務(wù)協(xié)調(diào)器收到回復(fù)， 只要有一方回復(fù)no則分別向參與者發(fā)起回滾事務(wù)， 參與者開始回滾事務(wù)。
4、 事務(wù)協(xié)調(diào)器收到回復(fù)， 全部回復(fù)yes， 此時向參與者發(fā)起提交事務(wù)。如果參與者有一方提交事務(wù)失敗則由事務(wù)協(xié)調(diào)器發(fā)起回滾事務(wù)。
2PC的優(yōu)點：實現(xiàn)強(qiáng)一致性， 部分關(guān)系數(shù)據(jù)庫支持（ Oracle、 MySQL等） 。
缺點：整個事務(wù)的執(zhí)行需要由協(xié)調(diào)者在多個節(jié)點之間去協(xié)調(diào)， 增加了事務(wù)的執(zhí)行時間， 性能低下。
解決方案有：springboot+Atomikos or Bitronix

跨服務(wù)事務(wù)

主要有：

1）TCC

2）本地消息表

3）可靠消息

4）最大努力通知

2）事務(wù)補償（TCC）

    TCC將一個大的事務(wù)拆分成兩階段的多個子事務(wù)。其中第一階段的子事務(wù)和第二階段的子事務(wù)獨立。【第一階段和第二階段異步執(zhí)行，不影響事務(wù)的整體特性】。TCC分布式事務(wù)不違反CAP和BASE等分布式系統(tǒng)一致性理論，TCC通過第二階段的補償機(jī)制來實現(xiàn)最終一致性。所有的分布式事務(wù)都需要有補償機(jī)制，都屬于最終一致性，方案的選型【重點】在以補償機(jī)制的效率。TCC在極端情況下需要人工介入。TCC異常可能會導(dǎo)致系統(tǒng)不一致。在金融系統(tǒng)中需要獨立的賬務(wù)檢查系統(tǒng)。

每個服務(wù)都要實現(xiàn) try/conform/cancel 方法

TCC事務(wù)補償是基于2PC實現(xiàn)的業(yè)務(wù)層事務(wù)控制方案， 它是Try、Confirm和Cancel三個單詞的首字母， 含義如下：
1、Try 檢查及預(yù)留業(yè)務(wù)資源完成提交事務(wù)前的檢查，并預(yù)留好資源。每一個try是一個子事務(wù)，所有try方法成功才是成功，try對應(yīng)第一階段。
2、Confirm 確定執(zhí)行業(yè)務(wù)操作對try階段預(yù)留的資源正式執(zhí)行。try成功后執(zhí)行conform，每一個conform為一個獨立子事務(wù)，conform為第二階段事務(wù)。try和conform是相互獨立的。
3、Cancel 取消執(zhí)行業(yè)務(wù)操作對try階段預(yù)留的資源釋放。只要有一個try執(zhí)行失敗，第二階段執(zhí)行cancel方法。

第一階段執(zhí)行成功之后，第二階段必須執(zhí)行成功。

1 、Try

    try階段做  業(yè)務(wù)檢查，【檢查庫存是否足夠，檢查銀行卡余額是否足夠】，做資源預(yù)留【對庫存、余額進(jìn)行凍結(jié)】。try階段決定分布式事務(wù)是否成功。
    下單業(yè)務(wù)由訂單服務(wù)和庫存服務(wù)協(xié)同完成， 在try階段訂單服務(wù)和庫存服務(wù)完成檢查和預(yù)留資源。訂單服務(wù)檢查當(dāng)前是否滿足提交訂單的條件（ 比如：當(dāng)前存在未完成訂單的不允許提交新訂單）。庫存服務(wù)檢查當(dāng)前是否有充足的庫存， 并鎖定資源。

2、 Confirm

    conform 執(zhí)行業(yè)務(wù)，【進(jìn)行冪等性檢查】。處理 try凍結(jié)的資源。try成功， conform 必須成功。【超過重試次數(shù)，人工介入】

    confirm 要進(jìn)行異常處理，并記錄日志。
    訂單服務(wù)和庫存服務(wù)成功完成Try后開始正式執(zhí)行資源操作。訂單服務(wù)向訂單寫一條訂單信息。庫存服務(wù)減去庫存。

3、 Cancel

    回滾業(yè)務(wù)，【進(jìn)行冪等性檢查】，釋放 try 凍結(jié)的資源， try 失敗， cancel 必須成功。【超過重試次數(shù)，人工介入】

    空回滾檢查：當(dāng) try網(wǎng)絡(luò)超時，回滾業(yè)務(wù)前要進(jìn)行檢查。具體方法：1）通過事務(wù)控制表識別空回滾。2）通過業(yè)務(wù)流水識別空回滾。
    如果訂單服務(wù)和庫存服務(wù)有一方出現(xiàn)失敗則全部取消操作。訂單服務(wù)需要刪除新增的訂單信息。庫存服務(wù)將減去的庫存再還原。

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

TCC的try/confirm/cancel接口都要實現(xiàn)冪等性， 在為在try、 confirm、 cancel失敗后要不斷重試。

流程：

1、業(yè)務(wù)服務(wù)向分布式事務(wù)管理器請求啟動事務(wù)，并執(zhí)行第一階段的 Try 調(diào)用其他服務(wù)。

2、其他服務(wù)返回 Try 結(jié)果。

3、全部成功或有失敗，向分布式事務(wù)管理器發(fā)起請求，提交或回滾事務(wù)。

4、分布式事務(wù)管理器執(zhí)行第二階段Conform或Cancel方法調(diào)用其他服務(wù)。

5、如果第二階段cancel、conform執(zhí)行失敗，分布式事務(wù)管理器會不斷重試。

TCC框架實現(xiàn)分布式事務(wù)管理器。如 Himly框架等。。。

3）冪等性

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

冪等操作實現(xiàn)方式有：
1 、 操作之前在業(yè)務(wù)方法進(jìn)行判斷如果執(zhí)行過了就不再執(zhí)行。

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

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

4、編程模型

5、分布式事務(wù)和本地事務(wù)沖突原則

@Transactional
@Hmily
public void update(){......}

本地事務(wù)會和分布式事務(wù)一起執(zhí)行，如上。

原則：本地事務(wù)不能影響分布式事務(wù)。

6、防懸掛

    Cancel比try先執(zhí)行。（try一直網(wǎng)絡(luò)超時，然后分布式事務(wù)執(zhí)行了cancel。Cancel執(zhí)行完之后，try執(zhí)行請求才到）。

如上，事務(wù)已經(jīng)結(jié)束，try 一定不能執(zhí)行。

7、微服務(wù)編程模型

8、互聯(lián)網(wǎng)優(yōu)化方案

1、第一階段執(zhí)行完成之后，第二階段用一個類似消息隊列的方式進(jìn)行異步執(zhí)行；

2、第一階段執(zhí)行完成之后，第二階段confirm提交同步執(zhí)行，cancel回滾異步執(zhí)行。

版權(quán)聲明：本文為博主原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接和本聲明。

本文鏈接：

https://blog.csdn.net/kepengs/article/details/110850342

鋒哥最新SpringCloud分布式電商秒殺課程發(fā)布

??????

??長按上方微信二維碼 2 秒

感謝點贊支持下哈