架構(gòu)師之路 — 分布式系統(tǒng) — 分布式事務(wù)難題

目錄

文章目錄

目錄

分布式事務(wù)難題

分布式事務(wù)的實(shí)現(xiàn)方式

2PC

2PC 階段一，執(zhí)行事務(wù)

2PC 階段二：提交事務(wù)

2PC 的 4 個(gè)缺點(diǎn)

3PC

3PC 第一階段 can commit

3PC 第二階段 pre commit

3PC 第三階段 do commit

3PC 的個(gè)缺點(diǎn)

分布式事務(wù)難題

隨著分布式計(jì)算的發(fā)展，事務(wù)在分布式計(jì)算領(lǐng)域也得到了廣泛的應(yīng)用。

在單機(jī)數(shù)據(jù)庫(kù)中，我們很容易能夠?qū)崿F(xiàn)一套滿足 ACID 特性的事務(wù)處理系統(tǒng)，但在分布式數(shù)據(jù)庫(kù)中，數(shù)據(jù)分散在各臺(tái)不同的機(jī)器上，如何對(duì)這些數(shù)據(jù)進(jìn)行分布式的事務(wù)處理具有非常大的挑戰(zhàn)。

原子性（Atomicity）要么全有，要么全無(wú)：指事務(wù)是一個(gè)不可分割的工作單位，事務(wù)中的操作要么都發(fā)生，要么都不發(fā)生。

一致性（Consistency）每次讀取的都必須是最新數(shù)據(jù)：指一個(gè)事務(wù)執(zhí)行之前和執(zhí)行之后數(shù)據(jù)庫(kù)都必須處于一致性狀態(tài)。如果事務(wù)成功地完成，那么系統(tǒng)中所有變化將正確地應(yīng)用，系統(tǒng)處于有效狀態(tài)。如果在事務(wù)中出現(xiàn)錯(cuò)誤，那么系統(tǒng)中的所有變化將自動(dòng)地回滾，系統(tǒng)返回到原始狀態(tài)，即：從一個(gè)一致性狀態(tài)變換到另外一個(gè)一致性狀態(tài)。

隔離性（Isolation）多并發(fā)事務(wù)互相隔離，對(duì)共享數(shù)據(jù)加鎖：指在并發(fā)環(huán)境中，當(dāng)不同的事務(wù)同時(shí)操縱相同的數(shù)據(jù)時(shí)，每個(gè)事務(wù)都有各自的完整數(shù)據(jù)空間。由并發(fā)事務(wù)所做的修改必須與任何其他并發(fā)事務(wù)所做的修改隔離。事務(wù)查看數(shù)據(jù)更新時(shí)，數(shù)據(jù)所處的狀態(tài)要么是另一事務(wù)修改它之前的狀態(tài)，要么是另一事務(wù)修改它之后的狀態(tài)，事務(wù)不會(huì)查看到中間狀態(tài)的數(shù)據(jù)。

持久性（Durability）數(shù)據(jù)最終的落盤變更是持久而不變的：指一個(gè)事務(wù)一旦被提交，它對(duì)數(shù)據(jù)庫(kù)中數(shù)據(jù)的改變就是永久性的，接下來(lái)即使數(shù)據(jù)庫(kù)發(fā)生故障也不應(yīng)該對(duì)其有任何影響。

分布式事務(wù)是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器分別位于分布式系統(tǒng)的不同節(jié)點(diǎn)上，通常一個(gè)分布式事務(wù)中會(huì)涉及對(duì)多個(gè)數(shù)據(jù)源或業(yè)務(wù)系統(tǒng)的操作。

可以設(shè)想一個(gè)最典型的分布式事務(wù)場(chǎng)景：一個(gè)跨銀行的轉(zhuǎn)賬操作涉及調(diào)用兩個(gè)異地的銀行服務(wù)，其中一個(gè)是本地銀行提供的取款服務(wù)，另一個(gè)則是目標(biāo)銀行提供的存款服務(wù)，這兩個(gè)服務(wù)本身是無(wú)狀態(tài)并且相互獨(dú)立的，共同構(gòu)成了一個(gè)完整的分布式事務(wù)。如果從本地銀行取款成功，但是因?yàn)槟撤N原因存款服務(wù)失敗了，那么就必須回滾到取款之前的狀態(tài)，否則用戶可能會(huì)發(fā)現(xiàn)自己的錢不翼而飛了。

從這個(gè)例子可以看到，一個(gè)分布式事務(wù)可以看做是多個(gè)分布式的操作序列組成的，例如上面例子的取款服務(wù)和存款服務(wù)，通常可以把這一系列分布式的操作序列稱為子事務(wù)。因此，分布式事務(wù)也可以被定義為一種嵌套型的事務(wù)，同時(shí)也就具有了 ACID 事務(wù)特性。但由于在分布式事務(wù)中，各個(gè)子事務(wù)的執(zhí)行是分布式的，因此要實(shí)現(xiàn)一種能夠保證 ACID 特性的分布式事務(wù)處理系統(tǒng)就顯得格外復(fù)雜。

分布式事務(wù)的實(shí)現(xiàn)方式

2PC

在事務(wù)的參與過(guò)程中會(huì)產(chǎn)生多個(gè)角色，暫時(shí)我們先這么理解，協(xié)調(diào)者負(fù)責(zé)事務(wù)的發(fā)起，而參與者負(fù)責(zé)執(zhí)行事務(wù)。假定存在下面的 3 個(gè)角色，分別是一個(gè)協(xié)調(diào)和兩個(gè)參與，此時(shí)我們需要 A、B 執(zhí)行一個(gè)事務(wù)，并且要求這個(gè)事務(wù)，要么同時(shí)成功，要么同時(shí)失敗。

2PC 也叫做二階段提交：

一步執(zhí)行

一步提交

2PC 階段一，執(zhí)行事務(wù)

此時(shí)協(xié)調(diào)者會(huì)先發(fā)出一個(gè)命令，要求參與者 A、B 都去執(zhí)行這個(gè)事務(wù)，但是不提交。

說(shuō)的再詳細(xì)一點(diǎn)，就會(huì)產(chǎn)生寫 redo，undo 的日志，鎖定資源，執(zhí)行事務(wù)。但是執(zhí)行完了之后，直接向協(xié)調(diào)者打報(bào)告，詢問(wèn)一下，大哥我能提交嗎？

這個(gè)在日常寫 Java 的過(guò)程中應(yīng)該經(jīng)常遇到，就是前面寫了一大堆操作，但是等到最后一定會(huì)寫一個(gè) conn.commit() 這樣的東西，這就是所謂的執(zhí)行但不提交。

2PC 階段二：提交事務(wù)

當(dāng)協(xié)調(diào)者收到第一階段中的所有事務(wù)參與者（圖中的 A，B）的反饋（這個(gè)反饋簡(jiǎn)單理解為，告訴協(xié)調(diào)者前面的第一階段執(zhí)行成功了）時(shí)，就發(fā)送命令讓所有參與者提交事務(wù)。

說(shuō)的再細(xì)一點(diǎn)，那就是協(xié)調(diào)者收到反饋，且所有參與者均響應(yīng)可以提交，則通知參與者進(jìn)行 commit，否則 rollback。

2PC 的 4 個(gè)缺點(diǎn)

性能：整個(gè)流程看下來(lái)就知道這明顯產(chǎn)生了同步阻塞，各個(gè)需要操作數(shù)據(jù)庫(kù)的節(jié)點(diǎn)都占用了數(shù)據(jù)庫(kù)的資源。只有當(dāng)協(xié)調(diào)者收到所有節(jié)點(diǎn)都準(zhǔn)備完畢的反饋，事務(wù)協(xié)調(diào)者才會(huì)通知 commit or rollback，而參與者執(zhí)行完這個(gè) commit or rollback 的操作后，才會(huì)去釋放資源。

單點(diǎn)故障：協(xié)調(diào)者才是這個(gè)事務(wù)的核心。假如此時(shí)協(xié)調(diào)者故障宕機(jī)，會(huì)導(dǎo)致通知無(wú)法傳達(dá)到參與者的問(wèn)題，比如收不到那個(gè) commit or rollback，整一個(gè)事務(wù)便會(huì)停滯。

數(shù)據(jù)不一致：協(xié)調(diào)者在第二階段會(huì)發(fā)送 commit or rollback。可是這并不能保證每一個(gè)節(jié)點(diǎn)都正常收到這個(gè)命令，所以會(huì)可能竄在，參與者 A 收到了命令，提交了事務(wù)，但是參與者 B 沒(méi)有。所以網(wǎng)絡(luò)波動(dòng)是永恒的病因，你永遠(yuǎn)無(wú)法躲開(kāi)這個(gè)因素。

不存在容錯(cuò)機(jī)制：這個(gè)協(xié)調(diào)者需要收到所有的節(jié)點(diǎn)反饋準(zhǔn)備完成才會(huì)下達(dá) commit 的指示，任意一個(gè)參與者的響應(yīng)沒(méi)有收到，協(xié)調(diào)者就會(huì)進(jìn)行等待，而且只要存在一個(gè)宕機(jī)的節(jié)點(diǎn)，都會(huì)使得整個(gè)事務(wù)失敗回滾。

3PC

3PC 在 2PC 的前提下進(jìn)行了一個(gè)改良，將 2PC 中的準(zhǔn)備階段進(jìn)行拆分，形成 3 個(gè)階段：

can commit

pre commit

do commit

并且引入超時(shí)機(jī)制，一旦事務(wù)參與者在指定時(shí)間內(nèi)沒(méi)有收到協(xié)調(diào)者的 commit or rollback 指令，就會(huì)自動(dòng)進(jìn)行本地 commit，解決協(xié)調(diào)者的單點(diǎn)故障問(wèn)題。

3PC 第一階段 can commit

協(xié)調(diào)者先進(jìn)行詢問(wèn)，參與者就根據(jù)自身的實(shí)際情況回答 yes or no。

3PC 第二階段 pre commit

如果參與者都是返回同意，協(xié)調(diào)者則向所有參與者發(fā)送預(yù)提交請(qǐng)求，并進(jìn)入準(zhǔn)備階段，這里的準(zhǔn)備階段其實(shí)就是讓參與者鎖定資源，等待指令，然后就是事務(wù)的執(zhí)行，此時(shí)也像 2PC 一樣，執(zhí)行但不提交。

3PC 第三階段 do commit

然后等待協(xié)調(diào)者的指令，此時(shí)如果遲遲等不到指令，一段時(shí)間后就會(huì)自行本地提交。

3PC 的個(gè)缺點(diǎn)

但是這樣也會(huì)存在弊端，比如協(xié)調(diào)者成功給 1，2 參與者都發(fā)送回滾，然后 3 剛好就沒(méi)收到，那么 3 就自動(dòng)提交了，所以超時(shí)機(jī)制其實(shí)并不能完全保證數(shù)據(jù)的一致性。

分布式 數(shù)據(jù)庫(kù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。