亚洲AV最新,日本男女日逼视频,中文字幕AV日韩

大家好，我是冰河~~

今天，咱們就暫時(shí)不聊【精通高并發(fā)系列】了，今天插播一下分布式事務(wù)，為啥？因?yàn)楸勇?lián)合貓大人共同創(chuàng)作的分布式事務(wù)領(lǐng)域的開(kāi)山之作——《深入理解分布式事務(wù)：原理與實(shí)戰(zhàn)》一書(shū)正式出版了，于2021年10月20日開(kāi)始在當(dāng)當(dāng)預(yù)售，當(dāng)天即登上當(dāng)當(dāng)新書(shū)榜第一的位置！

本地事務(wù)

本地事務(wù)流程

在介紹分布式事務(wù)之前，我們先來(lái)看看本地事務(wù)。首先，我們先來(lái)一張圖。

image

由上圖，我們可以看出，本地事務(wù)由資源管理器（比如DBMS，數(shù)據(jù)庫(kù)管理系統(tǒng)）在本地進(jìn)行管理。

本地事務(wù)的優(yōu)缺點(diǎn)

本地事務(wù)具備相應(yīng)的優(yōu)點(diǎn)，也有其不足。

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

支持嚴(yán)格的ACID屬性。
可靠，事務(wù)實(shí)現(xiàn)的效率高（只是在本地操作）。
可以只在RM（資源管理器）中操作事務(wù)。
編程模型簡(jiǎn)單。

缺點(diǎn)：

缺乏分布式事務(wù)的處理能力。
數(shù)據(jù)隔離的最小單元由RM（資源管理器決定），開(kāi)發(fā)人員無(wú)法決定數(shù)據(jù)隔離的最小單元。比如：數(shù)據(jù)庫(kù)中的一條記錄等。

ACID屬性

說(shuō)起事務(wù)，我們不得不提的就是事務(wù)的ACID屬性。

image

A（Atomic）：原子性，構(gòu)成事務(wù)的所有操作，要么都執(zhí)行完成，要么全部不執(zhí)行，不可能出現(xiàn)部分成功部分失敗的情況。
C（Consistency）：一致性，在事務(wù)執(zhí)行前后，數(shù)據(jù)庫(kù)的一致性約束沒(méi)有被破壞。比如：張三向李四轉(zhuǎn)100元，轉(zhuǎn)賬前和轉(zhuǎn)賬后的數(shù)據(jù)的正確狀態(tài)叫作一致性，如果出現(xiàn)張三轉(zhuǎn)出100元，李四賬戶(hù)沒(méi)有增加100元這就出現(xiàn)了數(shù) 據(jù)錯(cuò)誤，就沒(méi)有達(dá)到一致性。
I（Isolation）：隔離性，數(shù)據(jù)庫(kù)中的事務(wù)一般都是并發(fā)的，隔離性是指并發(fā)的兩個(gè)事務(wù)的執(zhí)行互不干擾，一個(gè)事務(wù)不能看到其他事務(wù)運(yùn)行過(guò)程的中間狀態(tài)。通過(guò)配置事務(wù)隔離級(jí)別可以避臟讀、重復(fù)讀等問(wèn)題。
D（Durability）：持久性，事務(wù)完成之后，該事務(wù)對(duì)數(shù)據(jù)的更改會(huì)被持久化到數(shù)據(jù)庫(kù)，且不會(huì)被回滾。

分布式事務(wù)

隨著業(yè)務(wù)的快速發(fā)展，網(wǎng)站系統(tǒng)往往由單體架構(gòu)逐漸演變?yōu)榉植际健⑽⒎?wù)架構(gòu)，而對(duì)于數(shù)據(jù)庫(kù)則由單機(jī)數(shù)據(jù)庫(kù)架構(gòu)向分布式數(shù)據(jù)庫(kù)架構(gòu)轉(zhuǎn)變。此時(shí)，我們會(huì)將一個(gè)大的應(yīng)用系統(tǒng)拆分為多個(gè)可以獨(dú)立部署的應(yīng)用服務(wù)，需要各個(gè)服務(wù)之間進(jìn)行遠(yuǎn)程協(xié)作才能完成事務(wù)操作。

我們可以使用下圖來(lái)表示剛開(kāi)始我們系統(tǒng)的單體架構(gòu)。

image

上圖中，我們將同一個(gè)項(xiàng)目中的不同模塊組織成不同的包來(lái)進(jìn)行管理，所有的程序代碼仍然是放在同一個(gè)項(xiàng)目中。

后續(xù)由于業(yè)務(wù)的發(fā)展，我們將其擴(kuò)展為分布式、微服務(wù)架構(gòu)。此時(shí)，我們將一個(gè)大的項(xiàng)目拆分為一個(gè)個(gè)小的可以獨(dú)立部署的微服務(wù)，每個(gè)微服務(wù)都有自己的數(shù)據(jù)庫(kù)，如下所示。

image

又比如，在我們的程序中，經(jīng)常會(huì)在同一個(gè)事務(wù)中執(zhí)行類(lèi)似如下的代碼來(lái)完成我們的需求。

<pre spellcheck="false" class="md-fences md-end-block ty-contain-cm modeLoaded" cid="n51" mdtype="fences" style="box-sizing: border-box; overflow: visible; font-family: var(--monospace); font-size: 0.9em; display: block; break-inside: avoid; text-align: left; white-space: normal; background-image: inherit; background-position: inherit; background-size: inherit; background-repeat: inherit; background-attachment: inherit; background-origin: inherit; background-clip: inherit; background-color: rgb(248, 248, 248); position: relative !important; border: 1px solid rgb(231, 234, 237); border-radius: 3px; padding: 8px 4px 6px; margin-bottom: 15px; margin-top: 15px; width: inherit; color: rgb(51, 51, 51); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;" lang="java">@Transactional(rollbackFor = Exception.class)
public void submitOrder() {
orderDao.update(); // 更新訂單信息
accountService.update(); // 修改資金賬戶(hù)的金額
pointService.update(); // 修改積分
accountingService.insert(); // 插入交易流水
merchantNotifyService.notify(); // 通知支付結(jié)果
}</pre>

上述代碼中的業(yè)務(wù)，僅僅在submitOrder()方法上添加了一個(gè)@Transactional注解，這能夠在分布式場(chǎng)景下避免分布式事務(wù)的問(wèn)題嗎？很顯然是不行的。

如果上述代碼所對(duì)應(yīng)的：訂單信息、資金賬戶(hù)信息、積分信息、交易流水等信息分別存儲(chǔ)在不同的數(shù)據(jù)里，而支付完成后，通知的目標(biāo)系統(tǒng)的數(shù)據(jù)同樣是存儲(chǔ)在不同的數(shù)據(jù)庫(kù)中。此時(shí)就會(huì)產(chǎn)生分布式事務(wù)問(wèn)題。

分布式事務(wù)產(chǎn)生的場(chǎng)景

跨JVM進(jìn)程

當(dāng)我們將單體項(xiàng)目拆分為分布式、微服務(wù)項(xiàng)目之后，各個(gè)服務(wù)之間通過(guò)遠(yuǎn)程REST或者RPC調(diào)用來(lái)協(xié)同完成業(yè)務(wù)操作。典型的場(chǎng)景就是：商城系統(tǒng)中的訂單微服務(wù)和庫(kù)存微服務(wù)，用戶(hù)在下單時(shí)會(huì)訪問(wèn)訂單微服務(wù)，訂單微服務(wù)在生成訂單記錄時(shí)，會(huì)調(diào)用庫(kù)存微服務(wù)來(lái)扣減庫(kù)存。各個(gè)微服務(wù)是部署在不同的JVM進(jìn)程中的，此時(shí)，就會(huì)產(chǎn)生因跨JVM進(jìn)程而導(dǎo)致的分布式事務(wù)問(wèn)題。

image

跨數(shù)據(jù)庫(kù)實(shí)例

單體系統(tǒng)訪問(wèn)多個(gè)數(shù)據(jù)庫(kù)實(shí)例，也就是跨數(shù)據(jù)源訪問(wèn)時(shí)會(huì)產(chǎn)生分布式事務(wù)。例如，我們的系統(tǒng)中的訂單數(shù)據(jù)庫(kù)和交易數(shù)據(jù)庫(kù)是放在不同的數(shù)據(jù)庫(kù)實(shí)例中，當(dāng)用戶(hù)發(fā)起退款時(shí)，會(huì)同時(shí)操作用戶(hù)的訂單數(shù)據(jù)庫(kù)和交易數(shù)據(jù)庫(kù)，在交易數(shù)據(jù)庫(kù)中執(zhí)行退款操作，在訂單數(shù)據(jù)庫(kù)中將訂單的狀態(tài)變更為已退款。由于數(shù)據(jù)分布在不同的數(shù)據(jù)庫(kù)實(shí)例，需要通過(guò)不同的數(shù)據(jù)庫(kù)連接會(huì)話(huà)來(lái)操作數(shù)據(jù)庫(kù)中的數(shù)據(jù)，此時(shí)，就產(chǎn)生了分布式事務(wù)。

image

多服務(wù)單數(shù)據(jù)庫(kù)

多個(gè)微服務(wù)訪問(wèn)同一個(gè)數(shù)據(jù)庫(kù)。例如，訂單微服務(wù)和庫(kù)存微服務(wù)訪問(wèn)同一個(gè)數(shù)據(jù)庫(kù)也會(huì)產(chǎn)生分布式事務(wù)，原因是：多個(gè)微服務(wù)訪問(wèn)同一個(gè)數(shù)據(jù)庫(kù)，本質(zhì)上也是通過(guò)不同的數(shù)據(jù)庫(kù)會(huì)話(huà)來(lái)操作數(shù)據(jù)庫(kù)，此時(shí)就會(huì)產(chǎn)生分布式事務(wù)。

image

注意：跨數(shù)據(jù)庫(kù)實(shí)例場(chǎng)景和多服務(wù)單數(shù)據(jù)庫(kù)場(chǎng)景，本質(zhì)上都是因?yàn)闀?huì)產(chǎn)生不同的數(shù)據(jù)庫(kù)會(huì)話(huà)來(lái)操作數(shù)據(jù)庫(kù)中的數(shù)據(jù)，進(jìn)而產(chǎn)生分布式事務(wù)。這兩種場(chǎng)景是大家比較容易忽略的。

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

知道了分布式事務(wù)產(chǎn)生的場(chǎng)景后，接下來(lái)，我們就聊聊分布式事務(wù)具體有哪些解決方案。

2PC方案

2PC即兩階段提交協(xié)議，是將整個(gè)事務(wù)流程分為兩個(gè)階段，準(zhǔn)備階段（Prepare phase）、提交階段（commit phase），2是指兩個(gè)階段，P是指準(zhǔn)備階段，C是指提交階段。

這里，我們用MySQL數(shù)據(jù)庫(kù)舉例，MySQL數(shù)據(jù)庫(kù)支持兩階段提交協(xié)議，可以分為成功和失敗兩種情況。

成功情況

image

失敗情況

image

具體流程如下：

準(zhǔn)備階段（Prepare phase）： 事務(wù)管理器給每個(gè)參與者發(fā)送Prepare消息，每個(gè)數(shù)據(jù)庫(kù)參與者在本地執(zhí)行事務(wù)，并寫(xiě)本地的Undo/Redo日志，此時(shí)事務(wù)沒(méi)有提交。（Undo日志是記錄修改前的數(shù)據(jù)，用于數(shù)據(jù)庫(kù)回滾，Redo日志是記錄修改后的數(shù)據(jù)，用于提交事務(wù)后寫(xiě)入數(shù) 據(jù)文件）

提交階段（commit phase）： 如果事務(wù)管理器收到了參與者的執(zhí)行失敗或者超時(shí)消息時(shí)，直接給每個(gè)參與者發(fā)送回滾(Rollback)消息；否則，發(fā)送提交(Commit)消息；參與者根據(jù)事務(wù)管理器的指令執(zhí)行提交或者回滾操作，并釋放事務(wù)處理過(guò)程中使用的鎖資源。

使用2PC方案時(shí)，需要注意的是：必須在最后階段釋放鎖資源。

可靠消息最終一致性方案

可靠消息最終一致性方案是指當(dāng)事務(wù)發(fā)起方執(zhí)行完成本地事務(wù)后并發(fā)出一條消息，事務(wù)參與方(消息消費(fèi)者)一定能夠接收消息并處理事務(wù)成功，此方案強(qiáng)調(diào)的是只要消息發(fā)給事務(wù)參與方最終事務(wù)要達(dá)到一致。

image

事務(wù)發(fā)起方（消息生產(chǎn)方）將消息發(fā)給消息中間件，事務(wù)參與方從消息中間件接收消息，事務(wù)發(fā)起方和消息中間件之間，事務(wù)參與方（消息消費(fèi)方）和消息中間件之間都是通過(guò)網(wǎng)絡(luò)通信，由于網(wǎng)絡(luò)通信的不確定性會(huì)導(dǎo)致分布式事務(wù)問(wèn)題。所以，我們?cè)诰唧w方案中會(huì)引入消息確認(rèn)服務(wù)和消息恢復(fù)服務(wù)。

使用可靠消息最終一致性方案時(shí)需要注意幾個(gè)問(wèn)題：

本地事務(wù)與消息發(fā)送的原子性問(wèn)題。
事務(wù)參與方接收消息的可靠性問(wèn)題。
消息重復(fù)消費(fèi)的問(wèn)題（需要實(shí)現(xiàn)冪等）。

TCC方案

TCC分為三個(gè)階段：

Try 階段 是做業(yè)務(wù)檢查(一致性)及資源預(yù)留(隔離)，此階段僅是一個(gè)初步操作，它和后續(xù)的Confirm 一起才能真正構(gòu)成一個(gè)完整的業(yè)務(wù)邏輯。
Confirm 階段 是做確認(rèn)提交，Try階段所有分支事務(wù)執(zhí)行成功后開(kāi)始執(zhí)行 Confirm。通常情況下，采用TCC則認(rèn)為 Confirm階段是不會(huì)出錯(cuò)的。即：只要Try成功，Confirm一定成功。若Confirm階段真的出錯(cuò)了，需引入重試機(jī)制或人工處理。
Cancel 階段 是在業(yè)務(wù)執(zhí)行錯(cuò)誤需要回滾的狀態(tài)下執(zhí)行分支事務(wù)的業(yè)務(wù)取消，預(yù)留資源釋放。通常情況下，采用TCC則認(rèn)為Cancel階段也是一定成功的。若Cancel階段真的出錯(cuò)了，需引入重試機(jī)制或人工處理。