本文分享自華為云社區(qū)《 》，作者： breakDawn。

隨著云原生的概念越來(lái)越火，服務(wù)的架構(gòu)應(yīng)該如何發(fā)展和演進(jìn)，成為很多程序員關(guān)心的話題。大名鼎鼎的《深入理解java虛擬機(jī)》一書(shū)作者于21年推出了新作《鳳凰架構(gòu)》，從這本書(shū)中可以看到當(dāng)前時(shí)下很多最新的技術(shù)或者理念。

因此本文以及后續(xù)都將持續(xù)沉淀發(fā)布這本書(shū)的學(xué)習(xí)筆記和思考，也歡迎購(gòu)買該書(shū)進(jìn)行詳細(xì)學(xué)習(xí)，或者關(guān)注后續(xù)的學(xué)習(xí)筆記內(nèi)容發(fā)布，了解精華內(nèi)容和總結(jié)思考。

(資料圖)

事務(wù)處理

事務(wù)有四個(gè)經(jīng)典的特性ACID：

原子性 (Atomicity):事務(wù)中的所有操作都必須是原子的，即不可分割或撤銷的。在一個(gè)事務(wù)執(zhí)行期間，所有的操作都必須同時(shí)成功或同時(shí)失敗，不存在中間狀態(tài)。 一致性 (Consistency):事務(wù)執(zhí)行的結(jié)果必須保證數(shù)據(jù)庫(kù)的一致性，即數(shù)據(jù)庫(kù)中的數(shù)據(jù)必須在事務(wù)開(kāi)始和結(jié)束時(shí)保持一致。 隔離性 (Isolation):事務(wù)之間的操作相互隔離，即一個(gè)事務(wù)的操作不會(huì)受到其他事務(wù)的影響。 可用性 (Availability):事務(wù)執(zhí)行期間數(shù)據(jù)庫(kù)必須保持可用，即可以在任何時(shí)候進(jìn)行訪問(wèn)和修改。

這四個(gè)特性ACID中， C其實(shí)是目的， AID是手段。只靠?jī)?nèi)部（單數(shù)據(jù)源）可以用AID實(shí)現(xiàn)C，但是外部（多數(shù)據(jù)源）的情況下沒(méi)法用AID保證C。

1 本地事務(wù)

本地事務(wù)是一種最基礎(chǔ)的事務(wù)解決方案，適用單個(gè)服務(wù)使用單個(gè)數(shù)據(jù)源的場(chǎng)景。 （注意，對(duì)于MyISAM來(lái)說(shuō)，代碼層面調(diào)用的rollback其實(shí)是空操作，引擎內(nèi)置了事務(wù)處理，不需要代碼調(diào)用rollback）

本地事務(wù)的實(shí)現(xiàn)原理來(lái)自ARIES（基于語(yǔ)義的恢復(fù)與隔離算法）

1.1 本地事務(wù)如何實(shí)現(xiàn)原子性和持久性

本地事務(wù)中， 寫(xiě)入磁盤(pán)的過(guò)程可能不是原子的，是會(huì)崩潰的。 因此要考慮2個(gè)異常情況：

未提交事務(wù)（調(diào)用事務(wù)的應(yīng)用層代碼未返回成功），數(shù)據(jù)還沒(méi)改完，寫(xiě)了一半崩潰了，導(dǎo)致數(shù)據(jù)不一致，非原子性 已提交事務(wù)（調(diào)用事務(wù)的應(yīng)用層代碼已經(jīng)反悔了），但是實(shí)際磁盤(pán)內(nèi)容還沒(méi)寫(xiě)就崩了，導(dǎo)致數(shù)據(jù)完全沒(méi)變化，非持久性。

解決方式：

引入commit log， 即將事務(wù)對(duì)數(shù)據(jù)的修改先寫(xiě)入commit log，寫(xiě)入成功代表事務(wù)成功，寫(xiě)入完成后再寫(xiě)磁盤(pán)，如果中途崩潰了就重新寫(xiě)入，等同于熟知的redo-log！

這也是為什么redo-log中是針對(duì)某個(gè)物理塊的修改，目的就是能正確重新，不用考慮我寫(xiě)到哪個(gè)位置了，直接全部重刷即可。

但是這樣性能太慢，希望能在事務(wù)提交完成前提前寫(xiě)入磁盤(pán)，但是提前寫(xiě)的話可能會(huì)非原子。 這時(shí)候就可以引入 undolog， 即觸發(fā)回滾時(shí)，可以講已操作的數(shù)據(jù)進(jìn)行undo回滾操作。 這也是為什么undo-log記錄的是一條條不可重復(fù)執(zhí)行的語(yǔ)句。

文中還提了2個(gè)特征：

NO-FORCE：事務(wù)提交后，不強(qiáng)求立刻全部寫(xiě)入磁盤(pán)，可以延遲(commit-log，有這的存在就不著急了） STEAL：事務(wù)提交前，可以先寫(xiě)入一部分?jǐn)?shù)據(jù)（undo-log）

1.2 本地事務(wù)如何實(shí)現(xiàn)隔離性

隔離性主要就是依賴 數(shù)據(jù)庫(kù)鎖和數(shù)據(jù)庫(kù)隔離級(jí)別實(shí)現(xiàn)。書(shū)中用作者自己的話簡(jiǎn)述了一遍從 可串行化 到 可重復(fù)讀 到 讀已提交 到讀未提交的 演變過(guò)程和實(shí)現(xiàn)原理， 也提了以下MVCC等內(nèi)容。

看完后感覺(jué)和我這篇文章講的內(nèi)容基本對(duì)的上： 里面有幾句比較重要的話：

MYSQL/Innodb的“可重復(fù)讀級(jí)別”只能在“只讀”事務(wù)中解決幻讀問(wèn)題，但是讀寫(xiě)事務(wù)還是會(huì)幻讀 讀未提交仍然是包含了寫(xiě)鎖的。 MVCC只是針對(duì)讀+寫(xiě)的場(chǎng)景做了優(yōu)化， 如果是寫(xiě)+寫(xiě)是沒(méi)法優(yōu)化的，只能用鎖。 范圍鎖不是指對(duì)范圍內(nèi)的每一條記錄加鎖， 而是整個(gè)范圍內(nèi)甚至都不能做插入了，即包含了間隙的鎖。

2 全局事務(wù)

這里的全局事務(wù)指的是 單個(gè)服務(wù) 使用 多個(gè)數(shù)據(jù)源。 核心在于是單個(gè)服務(wù)，不涉及多服務(wù)之間的關(guān)聯(lián)， 視角只有單服務(wù)。

XA接口是雙向的，能在一個(gè)事務(wù)管理器和多個(gè)資源管理器之間形成通信橋梁，協(xié)調(diào)多個(gè)數(shù)據(jù)源的一致動(dòng)作，實(shí)現(xiàn)全局事務(wù)的統(tǒng)一提交和回滾。Java基于XA接口衍生出的API叫做JTA（javax.transaction.TrancsactionManager和 XAResource）

注意對(duì)于全局事務(wù)，調(diào)用XA的應(yīng)用者是可以不需要額外處理的，XA會(huì)協(xié)助做好以下全局事務(wù)的響應(yīng)操作。

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

準(zhǔn)備階段

數(shù)據(jù)源將需要做的事務(wù)操作記錄在redolog中，完成了持久化，并仍舊持有鎖，保持隔離性

提交階段

協(xié)調(diào)者收到了所有數(shù)據(jù)源的回應(yīng)后， 給所有數(shù)據(jù)源發(fā)送commit指令，如果有任一失敗或者超時(shí)，則發(fā)送abort回滾指令。

2PC的缺點(diǎn)：

協(xié)調(diào)者單點(diǎn)問(wèn)題:協(xié)調(diào)者掛了其他的數(shù)據(jù)源都會(huì)一直在持有鎖的情況下等待 準(zhǔn)備階段的性能問(wèn)題：整個(gè)過(guò)程將被最慢的那個(gè)數(shù)據(jù)源所拖累，包括如果連接超時(shí)也會(huì)影響，導(dǎo)致多余的回滾操作 一致性風(fēng)險(xiǎn)：指令丟失、數(shù)據(jù)源機(jī)器崩潰且無(wú)法恢復(fù)（FLP不可能原理：如果岱機(jī)后無(wú)法恢復(fù)，那么沒(méi)有任何分布式協(xié)議可以達(dá)成一致性）

2.2 3PC協(xié)議

為了解決上面的單點(diǎn)問(wèn)題和 準(zhǔn)備階段的性能問(wèn)題，引入3PC協(xié)議 將準(zhǔn)備階段擴(kuò)展為：

CanCommit詢問(wèn)階段

這個(gè)階段就是為了確認(rèn)各機(jī)器是否還是正常的，如果經(jīng)過(guò)確認(rèn)都是正常負(fù)載的狀態(tài)，再下發(fā)事務(wù)操作，這樣就能避免被網(wǎng)絡(luò)超時(shí)、不良負(fù)載拖累的風(fēng)險(xiǎn)

PreCommit預(yù)提交階段

和之前一樣，下發(fā)事務(wù)后各數(shù)據(jù)源寫(xiě)入重做日志

DoCommit階段

這個(gè)過(guò)程有一個(gè)優(yōu)化， 如果協(xié)調(diào)者掛了， 數(shù)據(jù)源遲遲無(wú)法收到，就會(huì)默認(rèn)進(jìn)行事務(wù)提交（注意并非默認(rèn)回滾），3PC仍然存在網(wǎng)絡(luò)問(wèn)題導(dǎo)致的一致性問(wèn)題。

3 共享事務(wù)

書(shū)里說(shuō)這個(gè)不常用，不寫(xiě)了，類似于提供共享的數(shù)據(jù)連接給不同進(jìn)程使用，使用同一個(gè)事務(wù)邏輯

4 分布式事務(wù)

4.1 CAP理論

C一致性： 各節(jié)點(diǎn)同一時(shí)刻響應(yīng)結(jié)果一致（數(shù)據(jù)一致） A可用性： 各節(jié)點(diǎn)隨時(shí)隨地都要能正常響應(yīng)，不能存在延遲或者阻塞的情況（快速響應(yīng)） P分區(qū)容忍性：某個(gè)節(jié)點(diǎn)掛了，其他節(jié)點(diǎn)能代替服務(wù)

科學(xué)家證明CAP只能同時(shí)滿足2個(gè)

放棄分區(qū)容忍性P： 意味著分布式系統(tǒng)不成立。這種情況只有類似于Oracle RAC這種數(shù)據(jù)通過(guò)磁盤(pán)共享的情況， 雖然是多個(gè)實(shí)例，但不算分布式。 基本是分布式系統(tǒng)一定都會(huì)包含P，否則沒(méi)有考慮分布式事務(wù)的意義 放棄可用性A： 這樣可能因?yàn)閿?shù)據(jù)同步過(guò)程的延遲或者超時(shí)，造成系統(tǒng)長(zhǎng)時(shí)間不可用， 這是不能容忍的 放棄一致性C： 數(shù)據(jù)有短暫不一致的響應(yīng)。 放棄C是當(dāng)前分布式系統(tǒng)的主流選擇 。 一般都是允許數(shù)據(jù)在中間過(guò)程出錯(cuò)， 但允許在輸出時(shí)能夠修正古來(lái)。 因此我們放棄了強(qiáng)一致性，追求“最終一致性”

4.2 BASE（可靠性隊(duì)列）

BASE指 基本可用性 + 柔性事務(wù) + 最終一致性， 或者叫做最大努力交付

實(shí)現(xiàn)原理是引入一個(gè)消息隊(duì)列，當(dāng)某個(gè)事務(wù)動(dòng)作發(fā)生異常時(shí)， 在輪詢階段不斷重試，直到成功

要求滿足冪等性

可靠性事件隊(duì)列只要第一步完成了，后續(xù)就沒(méi)有失敗回滾的概念，只許成功，不許失敗。

4.3 TCC事務(wù)

TCC用于解決BASE中無(wú)法解決的隔離性問(wèn)題，因?yàn)锽ASE不允許失敗，一定會(huì)執(zhí)行，如果涉及了超售等問(wèn)題將無(wú)法解決。

Try: 嘗試執(zhí)行階段， 會(huì)先進(jìn)行業(yè)務(wù)可執(zhí)行的檢查，并提前預(yù)留好需要扣除的資源（類似于凍結(jié)那一塊資源，但沒(méi)有實(shí)際去扣） Confirm:執(zhí)行階段，這個(gè)過(guò)程不再做任何檢查，直接執(zhí)行。如果網(wǎng)絡(luò)出錯(cuò)等緣故則一直重試，符合冪等 Cancel:執(zhí)行完成，釋放try階段中預(yù)留的業(yè)務(wù)資源，也要符合冪等。

和2PC很類似，但TCC是在用戶應(yīng)用代碼層面實(shí)現(xiàn)的，業(yè)務(wù)侵入性很高， 而2PC是基礎(chǔ)設(shè)施層面提供的。

4.4 SAGA事務(wù)

TCC中的缺點(diǎn)在于 try階段和cancel階段依賴用戶代碼實(shí)現(xiàn)，但如果你的業(yè)務(wù)不支持這種操作就麻煩了，比如扣款動(dòng)作是某個(gè)銀行做的， 他不支持預(yù)扣款的功能。

SAGA會(huì)把事務(wù)拆成很多個(gè)小事務(wù)T，按順序執(zhí)行， 并根據(jù)情況給事務(wù)T失敗時(shí)選擇是繼續(xù)重試T， 還是用補(bǔ)償事務(wù)C來(lái)替代重試

這樣像銀行無(wú)法預(yù)扣款也無(wú)法撤銷轉(zhuǎn)賬的問(wèn)題，可以改成自己系統(tǒng)來(lái)做中間者做轉(zhuǎn)賬操作。

也要引入SAGAlog機(jī)制避免長(zhǎng)串事務(wù)執(zhí)行過(guò)程中崩潰

總結(jié)

其實(shí)學(xué)習(xí)本文時(shí)，更重要的是思考為什么要學(xué)習(xí)這么多的事務(wù)概念和原理。在云原生時(shí)代。

像華為云提供的很多數(shù)據(jù)庫(kù)類型的云服務(wù)也都支持了分布式事務(wù)的能力，例如

華為云RDS分布式事務(wù)（https://support.huaweicloud.com/bestpractice-ddm/ddm_01_0004.html）： 基于2PC原理實(shí)現(xiàn)的MSDTC分布式事務(wù)協(xié)調(diào)器 華為云DDM事務(wù)模型（https://support.huaweicloud.com/bestpractice-ddm/ddm_01_0004.html）: 這里面的分布式事務(wù)模塊基于 MySQL XA 協(xié)議實(shí)現(xiàn)，XA 協(xié)議是對(duì) 2PC(Two Phase Commit) 事務(wù)模型的一種實(shí)現(xiàn)。 華為云DWS分布式事務(wù)（https://support.huaweicloud.com/twp-dws/dws_11_0021.html）: 基于強(qiáng)一致性的CSN事務(wù)機(jī)制,使用GaussDB分布式框架下的一個(gè)組件GTM以及從中獲取到的CSN值來(lái)處理事務(wù)。

畢竟云原生應(yīng)用程序通常由多個(gè)微服務(wù)組成，因此需要在微服務(wù)之間進(jìn)行通信，并保證事務(wù)的一致性。在這種情況下，就需要一種適用業(yè)務(wù)場(chǎng)景的分布式事務(wù)解決方案。比如TCC可以在微服務(wù)之間實(shí)現(xiàn)分布式事務(wù)的ACID特性，而且相對(duì)于其他方案，TCC更輕量級(jí)，對(duì)性能影響更小，但其他方案也有各自的適應(yīng)場(chǎng)景。

因此，分布式事務(wù)與云原生技術(shù)有很強(qiáng)的關(guān)聯(lián)，可以幫助云原生應(yīng)用程序?qū)崿F(xiàn)高效的分布式事務(wù)處理。當(dāng)使用某個(gè)關(guān)系型數(shù)據(jù)庫(kù)產(chǎn)品時(shí)，關(guān)注他們的分布式事務(wù)處理能力并分析是否適合自己當(dāng)前的業(yè)務(wù)場(chǎng)景，是非常重要的，也是本書(shū)該章節(jié)值得學(xué)習(xí)的一個(gè)理由。

關(guān)注 點(diǎn)擊下方，第一時(shí)間了解華為云新鮮技術(shù)~

標(biāo)簽：