前言

最近看了幾篇有關(guān)于分布式事務(wù)的博文,，做一下筆記。哈哈~

數(shù)據(jù)庫事務(wù)

數(shù)據(jù)庫事務(wù)（簡(jiǎn)稱：事務(wù)）,，是數(shù)據(jù)庫管理系統(tǒng)執(zhí)行過程中的一個(gè)邏輯單位,，由一個(gè)有限的數(shù)據(jù)庫操作序列構(gòu)成，這些操作要么全部執(zhí)行,要么全部不執(zhí)行,，是一個(gè)不可分割的工作單位,。

數(shù)據(jù)庫事務(wù)的幾個(gè)典型特性：原子性(Atomicity )、一致性( Consistency ),、隔離性( Isolation)和持久性(Durabilily),，簡(jiǎn)稱就是ACID。

• 原子性： 事務(wù)作為一個(gè)整體被執(zhí)行,，包含在其中的對(duì)數(shù)據(jù)庫的操作要么全部被執(zhí)行,，要么都不執(zhí)行。

• 一致性： 指在事務(wù)開始之前和事務(wù)結(jié)束以后,，數(shù)據(jù)不會(huì)被破壞,，假如A賬戶給B賬戶轉(zhuǎn)10塊錢，不管成功與否,，A和B的總金額是不變的,。

• 隔離性： 多個(gè)事務(wù)并發(fā)訪問時(shí)，事務(wù)之間是相互隔離的,，即一個(gè)事務(wù)不影響其它事務(wù)運(yùn)行效果,。簡(jiǎn)言之，就是事務(wù)之間是進(jìn)水不犯河水的,。

• 持久性： 表示事務(wù)完成以后,，該事務(wù)對(duì)數(shù)據(jù)庫所作的操作更改，將持久地保存在數(shù)據(jù)庫之中,。

事務(wù)的實(shí)現(xiàn)原理

本地事務(wù)

傳統(tǒng)的單服務(wù)器,，單關(guān)系型數(shù)據(jù)庫下的事務(wù)，就是本地事務(wù),。本地事務(wù)由資源管理器管理,，JDBC事務(wù)就是一個(gè)非常典型的本地事務(wù)。

事務(wù)日志

innodb事務(wù)日志包括redo log和undo log,。

redo log（重做日志）

redo log通常是物理日志,，記錄的是數(shù)據(jù)頁的物理修改,，而不是某一行或某幾行修改成怎樣，它用來恢復(fù)提交后的物理數(shù)據(jù)頁,。

undo log（回滾日志）

undo log是邏輯日志,，和redo log記錄物理日志的不一樣?？梢赃@樣認(rèn)為,，當(dāng)delete一條記錄時(shí)，undo log中會(huì)記錄一條對(duì)應(yīng)的insert記錄,，當(dāng)update一條記錄時(shí),，它記錄一條對(duì)應(yīng)相反的update記錄。

事務(wù)ACID特性的實(shí)現(xiàn)思想

• 原子性：是使用 undo log來實(shí)現(xiàn)的,，如果事務(wù)執(zhí)行過程中出錯(cuò)或者用戶執(zhí)行了rollback,，系統(tǒng)通過undo log日志返回事務(wù)開始的狀態(tài)。

• 持久性：使用 redo log來實(shí)現(xiàn),，只要redo log日志持久化了,，當(dāng)系統(tǒng)崩潰，即可通過redo log把數(shù)據(jù)恢復(fù),。

• 隔離性：通過鎖以及MVCC,使事務(wù)相互隔離開,。

• 一致性：通過回滾、恢復(fù),，以及并發(fā)情況下的隔離性,，從而實(shí)現(xiàn)一致性。

分布式事務(wù)

分布式事務(wù)： 就是指事務(wù)的參與者,、支持事務(wù)的服務(wù)器,、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點(diǎn)之上。簡(jiǎn)單來說,，分布式事務(wù)指的就是分布式系統(tǒng)中的事務(wù),，它的存在就是為了保證不同數(shù)據(jù)庫節(jié)點(diǎn)的數(shù)據(jù)一致性。

為什么需要分布式事務(wù),？接下來分兩方面闡述：

微服務(wù)架構(gòu)下的分布式事務(wù)

隨著互聯(lián)網(wǎng)的快速發(fā)展,，輕盈且功能劃分明確的微服務(wù)，登上了歷史舞臺(tái),。比如,，一個(gè)用戶下訂單,，購買直播禮物的服務(wù),，被拆分成三個(gè)service，分別是金幣服務(wù)（coinService）,，下訂單服務(wù)（orderService）,、禮物服務(wù)（giftService）,。這些服務(wù)都部署在不同的機(jī)器上（節(jié)點(diǎn)），對(duì)應(yīng)的數(shù)據(jù)庫（金幣數(shù)據(jù)庫,、訂單數(shù)據(jù)庫,、禮物數(shù)據(jù)庫）也在不同節(jié)點(diǎn)上。

用戶下單購買禮物,，禮物數(shù)據(jù)庫,、金幣數(shù)據(jù)庫、訂單數(shù)據(jù)庫在不同節(jié)點(diǎn)上,，用本地事務(wù)是不可以的,，那么如何保證不同數(shù)據(jù)庫（節(jié)點(diǎn)）上的數(shù)據(jù)一致性呢？這就需要分布式事務(wù)啦~

分庫分表下的分布式事務(wù)

隨著業(yè)務(wù)的發(fā)展,，數(shù)據(jù)庫的數(shù)據(jù)日益龐大,，超過千萬級(jí)別的數(shù)據(jù)，我們就需要對(duì)它分庫分表（以前公司是用mycat分庫分表,，后來用sharding-jdbc）,。一分庫，數(shù)據(jù)又分布在不同節(jié)點(diǎn)上啦,，比如有的在深圳機(jī)房,，有的在北京機(jī)房~你再想用本地事務(wù)去保證，已經(jīng)無動(dòng)于衷啦~還是需要分布式事務(wù)啦,。

比如A轉(zhuǎn)10塊給B,，A的賬戶數(shù)據(jù)是在北京機(jī)房，B的賬戶數(shù)據(jù)是在深圳機(jī)房,。流程如下：

CAP 理論&BASE 理論

學(xué)習(xí)分布式事務(wù),，當(dāng)然需要了解 CAP 理論和BASE 理論。

CAP理論

CAP理論作為分布式系統(tǒng)的基礎(chǔ)理論,，指的是在一個(gè)分布式系統(tǒng)中,， Consistency（一致性）、 Availability（可用性）,、Partition tolerance（分區(qū)容錯(cuò)性）,，這三個(gè)要素最多只能同時(shí)實(shí)現(xiàn)兩點(diǎn)。

一致性(C：Consistency)：

一致性是指數(shù)據(jù)在多個(gè)副本之間能否保持一致的特性,。例如一個(gè)數(shù)據(jù)在某個(gè)分區(qū)節(jié)點(diǎn)更新之后,，在其他分區(qū)節(jié)點(diǎn)讀出來的數(shù)據(jù)也是更新之后的數(shù)據(jù)。

可用性(A：Availability)：

可用性是指系統(tǒng)提供的服務(wù)必須一直處于可用的狀態(tài),，對(duì)于用戶的每一個(gè)操作請(qǐng)求總是能夠在有限的時(shí)間內(nèi)返回結(jié)果,。這里的重點(diǎn)是"有限時(shí)間內(nèi)"和"返回結(jié)果"。

分區(qū)容錯(cuò)性（P:Partition tolerance）:

分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時(shí)候,，仍然需要能夠保證對(duì)外提供滿足一致性和可用性的服務(wù),。

BASE 理論

BASE 理論,， 是對(duì)CAP中AP的一個(gè)擴(kuò)展，對(duì)于我們的業(yè)務(wù)系統(tǒng),，我們考慮犧牲一致性來換取系統(tǒng)的可用性和分區(qū)容錯(cuò)性,。BASE是Basically Available(基本可用)，Soft state（軟狀態(tài)）,和 Eventually consistent（最終一致性）三個(gè)短語的縮寫,。

Basically Available

基本可用：通過支持局部故障而不是系統(tǒng)全局故障來實(shí)現(xiàn)的,。如將用戶分區(qū)在 5 個(gè)數(shù)據(jù)庫服務(wù)器上，一個(gè)用戶數(shù)據(jù)庫的故障只影響這臺(tái)特定主機(jī)那 20% 的用戶,，其他用戶不受影響,。

Soft State

軟狀態(tài)，狀態(tài)可以有一段時(shí)間不同步

Eventually Consistent

最終一致,，最終數(shù)據(jù)是一致的就可以了,，而不是時(shí)時(shí)保持強(qiáng)一致。

分布式事務(wù)的幾種解決方案

分布式事務(wù)解決方案主要有以下這幾種：

• 2PC(二階段提交)方案

• TCC（Try,、Confirm,、Cancel）

• 本地消息表

• 最大努力通知

• Saga事務(wù)

二階段提交方案

二階段提交方案是常用的分布式事務(wù)解決方案。事務(wù)的提交分為兩個(gè)階段：準(zhǔn)備階段和提交執(zhí)行方案,。

二階段提交成功的情況

準(zhǔn)備階段,，事務(wù)管理器向每個(gè)資源管理器發(fā)送準(zhǔn)備消息，如果資源管理器的本地事務(wù)操作執(zhí)行成功,，則返回成功,。

提交執(zhí)行階段，如果事務(wù)管理器收到了所有資源管理器回復(fù)的成功消息,，則向每個(gè)資源管理器發(fā)送提交消息,，RM 根據(jù) TM 的指令執(zhí)行提交。如圖：

二階段提交失敗的情況

準(zhǔn)備階段,，事務(wù)管理器向每個(gè)資源管理器發(fā)送準(zhǔn)備消息,，如果資源管理器的本地事務(wù)操作執(zhí)行成功，則返回成功,，如果執(zhí)行失敗,，則返回失敗。

提交執(zhí)行階段，如果事務(wù)管理器收到了任何一個(gè)資源管理器失敗的消息,，則向每個(gè)資源管理器發(fā)送回滾消息,。資源管理器根據(jù)事務(wù)管理器的指令回滾本地事務(wù)操作,，釋放所有事務(wù)處理過程中使用的鎖資源,。

二階段提交優(yōu)缺點(diǎn)

2PC方案實(shí)現(xiàn)起來簡(jiǎn)單，成本較低,，但是主要有以下缺點(diǎn)：

• 單點(diǎn)問題：如果事務(wù)管理器出現(xiàn)故障,，資源管理器將一直處于鎖定狀態(tài)。

• 性能問題：所有資源管理器在事務(wù)提交階段處于同步阻塞狀態(tài),，占用系統(tǒng)資源,，一直到提交完成，才釋放資源,，容易導(dǎo)致性能瓶頸,。

• 數(shù)據(jù)一致性問題：如果有的資源管理器收到提交的消息，有的沒收到,，那么會(huì)導(dǎo)致數(shù)據(jù)不一致問題,。

TCC（補(bǔ)償機(jī)制）

TCC 采用了補(bǔ)償機(jī)制，其核心思想是：針對(duì)每個(gè)操作,，都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)和補(bǔ)償（撤銷）操作,。

TCC（Try-Confirm-Cancel）模型

TCC（Try-Confirm-Cancel）是通過對(duì)業(yè)務(wù)邏輯的分解來實(shí)現(xiàn)分布式事務(wù)。針對(duì)一個(gè)具體的業(yè)務(wù)服務(wù),，TCC 分布式事務(wù)模型需要業(yè)務(wù)系統(tǒng)都實(shí)現(xiàn)一下三段邏輯：

try階段：嘗試去執(zhí)行,，完成所有業(yè)務(wù)的一致性檢查，預(yù)留必須的業(yè)務(wù)資源,。

Confirm階段：該階段對(duì)業(yè)務(wù)進(jìn)行確認(rèn)提交,，不做任何檢查，因?yàn)閠ry階段已經(jīng)檢查過了,，默認(rèn)Confirm階段是不會(huì)出錯(cuò)的,。

Cancel 階段：若業(yè)務(wù)執(zhí)行失敗，則進(jìn)入該階段,，它會(huì)釋放try階段占用的所有業(yè)務(wù)資源,，并回滾Confirm階段執(zhí)行的所有操作。

TCC 分布式事務(wù)模型包括三部分：主業(yè)務(wù)服務(wù),、從業(yè)務(wù)服務(wù),、業(yè)務(wù)活動(dòng)管理器。

• 主業(yè)務(wù)服務(wù)：主業(yè)務(wù)服務(wù)負(fù)責(zé)發(fā)起并完成整個(gè)業(yè)務(wù)活動(dòng),。

• 從業(yè)務(wù)服務(wù)：從業(yè)務(wù)服務(wù)是整個(gè)業(yè)務(wù)活動(dòng)的參與方,，實(shí)現(xiàn)Try、Confirm、Cancel操作,，供主業(yè)務(wù)服務(wù)調(diào)用,。

• 業(yè)務(wù)活動(dòng)管理器：業(yè)務(wù)活動(dòng)管理器管理控制整個(gè)業(yè)務(wù)活動(dòng)，包括記錄事務(wù)狀態(tài),，調(diào)用從業(yè)務(wù)服務(wù)的 Confirm 操作,，調(diào)用從業(yè)務(wù)服務(wù)的 Cancel 操作等。

下面再拿用戶下單購買禮物作為例子來模擬TCC實(shí)現(xiàn)分布式事務(wù)的過程：

假設(shè)用戶A余額為100金幣,，擁有的禮物為5朵,。A花了10個(gè)金幣，下訂單,，購買10朵玫瑰,。余額、訂單,、禮物都在不同數(shù)據(jù)庫,。

TCC的Try階段：

• 生成一條訂單記錄，訂單狀態(tài)為待確認(rèn),。

• 將用戶A的賬戶金幣中余額更新為90,，凍結(jié)金幣為10（預(yù)留業(yè)務(wù)資源）

• 將用戶的禮物數(shù)量為5，預(yù)增加數(shù)量為10,。

• Try成功之后,，便進(jìn)入Confirm階段

• Try過程發(fā)生任何異常，均進(jìn)入Cancel階段

TCC的Confirm階段：

• 訂單狀態(tài)更新為已支付

• 更新用戶余額為90,，可凍結(jié)為0

• 用戶禮物數(shù)量更新為15,，預(yù)增加為0

• Confirm過程發(fā)生任何異常，均進(jìn)入Cancel階段

• Confirm過程執(zhí)行成功,，則該事務(wù)結(jié)束

TCC的Cancel階段：

• 修改訂單狀態(tài)為已取消

• 更新用戶余額回100

• 更新用戶禮物數(shù)量為5

TCC優(yōu)缺點(diǎn)

TCC方案讓應(yīng)用可以自定義數(shù)據(jù)庫操作的粒度,，降低了鎖沖突，可以提升性能,，但是也有以下缺點(diǎn)：

• 應(yīng)用侵入性強(qiáng),，try、confirm,、cancel三個(gè)階段都需要業(yè)務(wù)邏輯實(shí)現(xiàn),。

• 需要根據(jù)網(wǎng)絡(luò)、系統(tǒng)故障等不同失敗原因?qū)崿F(xiàn)不同的回滾策略,，實(shí)現(xiàn)難度大,，一般借助TCC開源框架，ByteTCC,，TCC-transaction,，Himly,。

本地消息表

ebay最初提出本地消息表這個(gè)方案，來解決分布式事務(wù)問題,。業(yè)界目前使用這種方案是比較多的,，它的核心思想就是將分布式事務(wù)拆分成本地事務(wù)進(jìn)行處理?？梢钥匆幌禄镜膶?shí)現(xiàn)流程圖：

基本實(shí)現(xiàn)思路

發(fā)送消息方：

• 需要有一個(gè)消息表,，記錄著消息狀態(tài)相關(guān)信息。

• 業(yè)務(wù)數(shù)據(jù)和消息表在同一個(gè)數(shù)據(jù)庫,，即要保證它倆在同一個(gè)本地事務(wù),。

• 在本地事務(wù)中處理完業(yè)務(wù)數(shù)據(jù)和寫消息表操作后,，通過寫消息到MQ消息隊(duì)列,。

• 消息會(huì)發(fā)到消息消費(fèi)方，如果發(fā)送失敗,，即進(jìn)行重試,。

消息消費(fèi)方：

• 處理消息隊(duì)列中的消息，完成自己的業(yè)務(wù)邏輯,。

• 此時(shí)如果本地事務(wù)處理成功,，則表明已經(jīng)處理成功了。

• 如果本地事務(wù)處理失敗,，那么就會(huì)重試執(zhí)行,。

• 如果是業(yè)務(wù)上面的失敗，給消息生產(chǎn)方發(fā)送一個(gè)業(yè)務(wù)補(bǔ)償消息,，通知進(jìn)行回滾等操作,。

生產(chǎn)方和消費(fèi)方定時(shí)掃描本地消息表，把還沒處理完成的消息或者失敗的消息再發(fā)送一遍,。如果有靠譜的自動(dòng)對(duì)賬補(bǔ)賬邏輯,，這種方案還是非常實(shí)用的。

優(yōu)點(diǎn)&缺點(diǎn)：

該方案的優(yōu)點(diǎn)是很好地解決了分布式事務(wù)問題,，實(shí)現(xiàn)了最終一致性,。缺點(diǎn)是消息表會(huì)耦合到業(yè)務(wù)系統(tǒng)中。

最大努力通知

什么是最大通知

最大努力通知也是一種分布式事務(wù)解決方案,。下面是企業(yè)網(wǎng)銀轉(zhuǎn)賬一個(gè)例子

• 企業(yè)網(wǎng)銀系統(tǒng)調(diào)用前置接口,，跳轉(zhuǎn)到轉(zhuǎn)賬頁

• 企業(yè)網(wǎng)銀調(diào)用轉(zhuǎn)賬系統(tǒng)接口

• 轉(zhuǎn)賬系統(tǒng)完成轉(zhuǎn)賬處理，向企業(yè)網(wǎng)銀系統(tǒng)發(fā)起轉(zhuǎn)賬結(jié)果通知,，若通知失敗,，則轉(zhuǎn)賬系統(tǒng)按策略進(jìn)行重復(fù)通知。

• 企業(yè)網(wǎng)銀系統(tǒng)未接收到通知,，會(huì)主動(dòng)調(diào)用轉(zhuǎn)賬系統(tǒng)的接口查詢轉(zhuǎn)賬結(jié)果,。

• 轉(zhuǎn)賬系統(tǒng)會(huì)遇到退匯等情況,，會(huì)定時(shí)回來對(duì)賬。

最大努力通知方案的目標(biāo),，就是發(fā)起通知方通過一定的機(jī)制,，最大努力將業(yè)務(wù)處理結(jié)果通知到接收方。最大努力通知實(shí)現(xiàn)機(jī)制如下：

最大努力通知解決方案

要實(shí)現(xiàn)最大努力通知,，可以采用MQ的ack機(jī)制,。

方案

• 1.發(fā)起方將通知發(fā)給MQ。

• 2.接收通知方監(jiān)聽MQ消息,。

• 3.接收通知方收到消息后,，處理完業(yè)務(wù)，回應(yīng)ack,。

• 4.接收通知方若沒有回應(yīng)ack,，則MQ會(huì)間隔1min、5min,、10min等重復(fù)通知,。

• 5.接受通知方可用消息校對(duì)接口，保證消息的一致性,。

轉(zhuǎn)賬業(yè)務(wù)實(shí)現(xiàn)流程圖：

交互流程如下：

• 1,、用戶請(qǐng)求轉(zhuǎn)賬系統(tǒng)進(jìn)行轉(zhuǎn)賬。

• 2,、轉(zhuǎn)賬系統(tǒng)完成轉(zhuǎn)賬,，將轉(zhuǎn)賬結(jié)果發(fā)給MQ。

• 3,、企業(yè)網(wǎng)銀系統(tǒng)監(jiān)聽MQ,，接收轉(zhuǎn)賬結(jié)果通知，如果接收不到消息,，MQ會(huì)重復(fù)發(fā)送通知,。接收到轉(zhuǎn)賬結(jié)果，更新轉(zhuǎn)賬狀態(tài),。

• 4,、企業(yè)網(wǎng)銀系統(tǒng)也可以主動(dòng)查詢轉(zhuǎn)賬系統(tǒng)的轉(zhuǎn)賬結(jié)果查詢接口，更新轉(zhuǎn)賬狀態(tài),。

Saga事務(wù)

Saga事務(wù)由普林斯頓大學(xué)的Hector Garcia-Molina和Kenneth Salem提出,，其核心思想是將長(zhǎng)事務(wù)拆分為多個(gè)本地短事務(wù)，由Saga事務(wù)協(xié)調(diào)器協(xié)調(diào),，如果正常結(jié)束那就正常完成,，如果某個(gè)步驟失敗，則根據(jù)相反順序一次調(diào)用補(bǔ)償操作,。

saga簡(jiǎn)介

• Saga = Long Live Transaction (LLT,，長(zhǎng)活事務(wù))

• LLT = T1 + T2 + T3 + ... + Ti（Ti為本地短事務(wù)）

• 每個(gè)本地事務(wù)Ti 有對(duì)應(yīng)的補(bǔ)償 Ci

Saga的執(zhí)行順序

• 正常情況：T1 T2 T3 ... Tn

• 異常情況：T1 T2 T3 C3 C2 C1

Saga兩種恢復(fù)策略

• 向后恢復(fù),，如果任意本地子事務(wù)失敗，補(bǔ)償已完成的事務(wù),。如異常情況的執(zhí)行順序T1 T2 Ti Ci C2 C1.

• 向前恢復(fù),，即重試失敗的事務(wù)，假設(shè)最后每個(gè)子事務(wù)都會(huì)成功,。執(zhí)行順序：T1, T2, ..., Tj(失敗), Tj(重試),..., Tn,。

舉個(gè)例子，假設(shè)用戶下訂單,，花10塊錢購買了10多玫瑰,，則有

T1=下訂單 ，T2=扣用戶10塊錢,，T3=用戶加10朵玫瑰,， T4=庫存減10朵玫瑰

C1=取消訂單 ，C2= 給用戶加10塊錢,，C3 =用戶減10朵玫瑰,， C4=庫存加10朵玫瑰

假設(shè)事務(wù)執(zhí)行到T4發(fā)生異?；貪L,，在C4的要把玫瑰給庫存加回去的時(shí)候，發(fā)現(xiàn)用戶的玫瑰都用掉了,，這是Saga的一個(gè)缺點(diǎn),，由于事務(wù)之間沒有隔離性導(dǎo)致的問題。

可以通過以下方案解決這個(gè)問題：

• 在應(yīng)?層?加?邏輯鎖的邏輯,。

• Session層?隔離來保證串?化操作,。

• 業(yè)務(wù)層?采?預(yù)先凍結(jié)資?的?式隔離此部分資?。

• 業(yè)務(wù)操作過程中通過及時(shí)讀取當(dāng)前狀態(tài)的?式獲取更新,。

參考與感謝

• 干貨 | 一篇文章帶你學(xué)習(xí)分布式事務(wù)

• 再有人問你分布式事務(wù),，把這篇扔給他

• 聊聊分布式事務(wù)，再說說解決方案

• Mysql事務(wù)實(shí)現(xiàn)原理

• 詳細(xì)分析MySQL事務(wù)日志(redo log和undo log)

• 《Saga分布式事務(wù)解決?案與實(shí)踐》

• 分布式事務(wù)解決方案之最大努力通知

個(gè)人公眾號(hào)

• 覺得寫得好的小伙伴給個(gè)點(diǎn)贊+關(guān)注啦,，謝謝~

• 同時(shí)非常期待小伙伴們能夠關(guān)注我公眾號(hào),，后面慢慢推出更好的干貨~嘻嘻