亚洲视频在线网站,国产亚洲精品福利片,毛片一级毛片

最近看了幾篇有關(guān)于分布式事務(wù)的博文，做了一下筆記，并總結(jié)出這篇文章。

圖片來(lái)自 Pexels

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

數(shù)據(jù)庫(kù)事務(wù)(簡(jiǎn)稱：事務(wù))，是數(shù)據(jù)庫(kù)管理系統(tǒng)執(zhí)行過(guò)程中的一個(gè)邏輯單位，由一個(gè)有限的數(shù)據(jù)庫(kù)操作序列構(gòu)成。

這些操作要么全部執(zhí)行，要么全部不執(zhí)行，是一個(gè)不可分割的工作單位。

數(shù)據(jù)庫(kù)事務(wù)的幾個(gè)典型特性：

原子性(Atomicity)
一致性(Consistency)
隔離性(Isolation)
持久性(Durabilily)

簡(jiǎn)稱就是 ACID：

原子性：事務(wù)作為一個(gè)整體被執(zhí)行，包含在其中的對(duì)數(shù)據(jù)庫(kù)的操作要么全部被執(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ù)庫(kù)所作的操作更改，將持久地保存在數(shù)據(jù)庫(kù)之中。

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

本地事務(wù)

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

事務(wù)日志

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

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

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 來(lái)實(shí)現(xiàn)的，如果事務(wù)執(zhí)行過(guò)程中出錯(cuò)或者用戶執(zhí)行了 rollback，系統(tǒng)通過(guò) undo log 日志返回事務(wù)開始的狀態(tài)。
持久性：使用 redo log 來(lái)實(shí)現(xiàn)，只要 redo log 日志持久化了，當(dāng)系統(tǒng)崩潰，即可通過(guò) redo log 把數(shù)據(jù)恢復(fù)。
隔離性：通過(guò)鎖以及 MVCC，使事務(wù)相互隔離開。
一致性：通過(guò)回滾、恢復(fù)，以及并發(fā)情況下的隔離性，從而實(shí)現(xiàn)一致性。

分布式事務(wù)

分布式事務(wù)就是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點(diǎn)之上。

簡(jiǎn)單來(lái)說(shuō)，分布式事務(wù)指的就是分布式系統(tǒng)中的事務(wù)，它的存在就是為了保證不同數(shù)據(jù)庫(kù)節(jié)點(diǎn)的數(shù)據(jù)一致性。

為什么需要分布式事務(wù)?接下來(lái)分兩方面闡述：

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

隨著互聯(lián)網(wǎng)的快速發(fā)展，輕盈且功能劃分明確的微服務(wù)，登上了歷史舞臺(tái)。

比如，一個(gè)用戶下訂單，購(gòu)買直播禮物的服務(wù)，被拆分成三個(gè) service，分別是金幣服務(wù)(coinService)，下訂單服務(wù)(orderService)、禮物服務(wù)(giftService)。

這些服務(wù)都部署在不同的機(jī)器上(節(jié)點(diǎn))，對(duì)應(yīng)的數(shù)據(jù)庫(kù)(金幣數(shù)據(jù)庫(kù)、訂單數(shù)據(jù)庫(kù)、禮物數(shù)據(jù)庫(kù))也在不同節(jié)點(diǎn)上。

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

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

隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)庫(kù)的數(shù)據(jù)日益龐大，超過(guò)千萬(wàn)級(jí)別的數(shù)據(jù)，我們就需要對(duì)它分庫(kù)分表(以前公司是用 Mycat 分庫(kù)分表，后來(lái)用 Sharding-JDBC)。

一分庫(kù)，數(shù)據(jù)又分布在不同節(jié)點(diǎn)上啦，比如有的在深圳機(jī)房，有的在北京機(jī)房~你再想用本地事務(wù)去保證，已經(jīng)無(wú)動(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)讀出來(lái)的數(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)，我們考慮犧牲一致性來(lái)?yè)Q取系統(tǒng)的可用性和分區(qū)容錯(cuò)性。

BASE 是 Basically Available(基本可用)，Soft State(軟狀態(tài))和 Eventually Consistent(最終一致性)三個(gè)短語(yǔ)的縮寫。

Basically Available：基本可用。通過(guò)支持局部故障而不是系統(tǒng)全局故障來(lái)實(shí)現(xiàn)的。

如將用戶分區(qū)在 5 個(gè)數(shù)據(jù)庫(kù)服務(wù)器上，一個(gè)用戶數(shù)據(jù)庫(kù)的故障只影響這臺(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ù)處理過(guò)程中使用的鎖資源。

2PC 方案實(shí)現(xiàn)起來(lái)簡(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)是通過(guò)對(duì)業(yè)務(wù)邏輯的分解來(lái)實(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)?Try 階段已經(jīng)檢查過(guò)了，默認(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ù)負(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 操作等。

下面再拿用戶下單購(gòu)買禮物作為例子來(lái)模擬 TCC 實(shí)現(xiàn)分布式事務(wù)的過(guò)程：假設(shè)用戶 A 余額為 100 金幣，擁有的禮物為 5 朵。A 花了 10 個(gè)金幣，下訂單，購(gòu)買 10 朵玫瑰。余額、訂單、禮物都在不同數(shù)據(jù)庫(kù)。

TCC 的 Try 階段：

生成一條訂單記錄，訂單狀態(tài)為待確認(rèn)。
將用戶 A 的賬戶金幣中余額更新為 90，凍結(jié)金幣為 10(預(yù)留業(yè)務(wù)資源)。
將用戶的禮物數(shù)量為 5，預(yù)增加數(shù)量為 10。
Try 成功之后，便進(jìn)入 Confirm 階段。
Try 過(guò)程發(fā)生任何異常，均進(jìn)入 Cancel 階段。

TCC 的 Confirm 階段：

訂單狀態(tài)更新為已支付。
更新用戶余額為 90，可凍結(jié)為 0。
用戶禮物數(shù)量更新為 15，預(yù)增加為 0。
Confirm 過(guò)程發(fā)生任何異常，均進(jìn)入 Cancel 階段。
Confirm 過(guò)程執(zhí)行成功，則該事務(wù)結(jié)束。

TCC 的 Cancel 階段：

修改訂單狀態(tài)為已取消。
更新用戶余額回 100。
更新用戶禮物數(shù)量為 5。

TCC 方案讓應(yīng)用可以自定義數(shù)據(jù)庫(kù)操作的粒度，降低了鎖沖突，可以提升性能。

但是也有以下缺點(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è)方案，來(lái)解決分布式事務(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ù)庫(kù)，即要保證它倆在同一個(gè)本地事務(wù)。
在本地事務(wù)中處理完業(yè)務(wù)數(shù)據(jù)和寫消息表操作后，通過(guò)寫消息到 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)：該方案的優(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è)。
企業(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í)回來(lái)對(duì)賬。

最大努力通知方案的目標(biāo)，就是發(fā)起通知方通過(guò)一定的機(jī)制，最大努力將業(yè)務(wù)處理結(jié)果通知到接收方。

最大努力通知實(shí)現(xiàn)機(jī)制如下：

最大努力通知解決方案：要實(shí)現(xiàn)最大努力通知，可以采用 MQ 的 ACK 機(jī)制。

方案如下：

發(fā)起方將通知發(fā)給 MQ。
接收通知方監(jiān)聽 MQ 消息。
接收通知方收到消息后，處理完業(yè)務(wù)，回應(yīng) ACK。
接收通知方若沒有回應(yīng) ACK，則 MQ 會(huì)間隔 1min、5min、10min 等重復(fù)通知。
接受通知方可用消息校對(duì)接口，保證消息的一致性。

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

交互流程如下：

用戶請(qǐng)求轉(zhuǎn)賬系統(tǒng)進(jìn)行轉(zhuǎn)賬。
轉(zhuǎn)賬系統(tǒng)完成轉(zhuǎn)賬，將轉(zhuǎn)賬結(jié)果發(fā)給 MQ。
企業(yè)網(wǎng)銀系統(tǒng)監(jiān)聽 MQ，接收轉(zhuǎn)賬結(jié)果通知，如果接收不到消息，MQ 會(huì)重復(fù)發(fā)送通知。接收到轉(zhuǎn)賬結(jié)果，更新轉(zhuǎn)賬狀態(tài)。
企業(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 塊錢購(gòu)買了 10 多玫瑰，則有：