前言

一般，數(shù)據(jù)庫事務(wù)的隔離級別會被設(shè)置成?讀已提交，已滿足業(yè)務(wù)需求，這樣對應(yīng)在Fescar中的分支（本地）事務(wù)的隔離級別就是?讀已提交，那么Fescar中對于全局事務(wù)的隔離級別又是什么呢？如果認(rèn)真閱讀了?分布式事務(wù)中間件Txc/Fescar-RM模塊源碼解讀?的同學(xué)應(yīng)該能推斷出來：Fescar將全局事務(wù)的默認(rèn)隔離定義成讀未提交。對于讀未提交隔離級別對業(yè)務(wù)的影響，想必大家都比較清楚，會讀到臟數(shù)據(jù)，經(jīng)典的就是銀行轉(zhuǎn)賬例子，出現(xiàn)數(shù)據(jù)不一致的問題。而對于Fescar，如果沒有采取任何其它技術(shù)手段，那會出現(xiàn)很嚴(yán)重的問題，比如：

如上圖所示，問最終全局事務(wù)A對資源R1應(yīng)該回滾到哪種狀態(tài)？很明顯，如果再根據(jù)UndoLog去做回滾，就會發(fā)生嚴(yán)重問題：覆蓋了全局事務(wù)B對資源R1的變更。那Fescar是如何解決這個問題呢？答案就是?Fescar的全局寫排它鎖解決方案，在全局事務(wù)A執(zhí)行過程中全局事務(wù)B會因為獲取不到全局鎖而處于等待狀態(tài)。
對于Fescar的隔離級別，引用官方的一段話來作說明：

全局事務(wù)的隔離性是建立在分支事務(wù)的本地隔離級別基礎(chǔ)之上的。
在數(shù)據(jù)庫本地隔離級別?讀已提交?或以上的前提下，Fescar 設(shè)計了由事務(wù)協(xié)調(diào)器維護(hù)的?全局寫排他鎖，來保證事務(wù)間的?寫隔離，將全局事務(wù)默認(rèn)定義在?讀未提交?的隔離級別上。
我們對隔離級別的共識是：絕大部分應(yīng)用在?讀已提交?的隔離級別下工作是沒有問題的。而實際上，這當(dāng)中又有絕大多數(shù)的應(yīng)用場景，實際上工作在?讀未提交?的隔離級別下同樣沒有問題。
在極端場景下，應(yīng)用如果需要達(dá)到全局的?讀已提交，Fescar 也提供了相應(yīng)的機(jī)制來達(dá)到目的。默認(rèn)，Fescar 是工作在?讀未提交?的隔離級別下，保證絕大多數(shù)場景的高效性。

下面，本文將深入到源碼層面對Fescar全局寫排它鎖實現(xiàn)方案進(jìn)行解讀。Fescar全局寫排它鎖實現(xiàn)方案在TC(Transaction Coordinator)模塊維護(hù)，RM(Resource Manager)模塊會在需要鎖獲取全局鎖的地方請求TC模塊以保證事務(wù)間的寫隔離，下面就分成兩個部分介紹：TC-全局寫排它鎖實現(xiàn)方案、RM-全局寫排它鎖使用

一、TC—全局寫排它鎖實現(xiàn)方案

首先看一下TC模塊與外部交互的入口，下圖是TC模塊的main函數(shù)：

上圖中看出RpcServer處理通信協(xié)議相關(guān)邏輯，而對于TC模塊真實處理器是DefaultCoordiantor，里面包含了所有TC對外暴露的功能，比如doGlobalBegin（全局事務(wù)創(chuàng)建）、doGlobalCommit（全局事務(wù)提交）、doGlobalRollback（全局事務(wù)回滾）、doBranchReport（分支事務(wù)狀態(tài)上報）、doBranchRegister（分支事務(wù)注冊）、doLockCheck（全局寫排它鎖校驗）等，其中doBranchRegister、doLockCheck、doGlobalCommit就是全局寫排它鎖實現(xiàn)方案的入口。

/** * 分支事務(wù)注冊，在注冊過程中會獲取分支事務(wù)的全局鎖資源 */ @Override protected void doBranchRegister(BranchRegisterRequest request, BranchRegisterResponse response,RpcContext rpcContext) throws TransactionException {response.setTransactionId(request.getTransactionId());response.setBranchId(core.branchRegister(request.getBranchType(), request.getResourceId(), rpcContext.getClientId(),XID.generateXID(request.getTransactionId()), request.getLockKey())); } /** * 校驗全局鎖能否被獲取到 */ @Override protected void doLockCheck(GlobalLockQueryRequest request, GlobalLockQueryResponse response, RpcContext rpcContext)throws TransactionException {response.setLockable(core.lockQuery(request.getBranchType(), request.getResourceId(),XID.generateXID(request.getTransactionId()), request.getLockKey())); } /** * 全局事務(wù)提交，會將全局事務(wù)下的所有分支事務(wù)的鎖占用記錄釋放 */ @Override protected void doGlobalCommit(GlobalCommitRequest request, GlobalCommitResponse response, RpcContext rpcContext) throws TransactionException {response.setGlobalStatus(core.commit(XID.generateXID(request.getTransactionId()))); }

上述代碼邏輯最后會被代理到DefualtCore去做執(zhí)行

如上圖，不管是獲取鎖還是校驗鎖狀態(tài)邏輯，最終都會被LockManger所接管，而LockManager的邏輯由DefaultLockManagerImpl實現(xiàn)，所有與全局寫排它鎖的設(shè)計都在DefaultLockManagerImpl中維護(hù)。
首先，就先來看一下全局寫排它鎖的結(jié)構(gòu)：

private static final ConcurrentHashMap<String, ConcurrentHashMap<String, ConcurrentHashMap<Integer, Map<String, Long>>>> LOCK_MAP = new ConcurrentHashMap<~>();

整體上，鎖結(jié)構(gòu)采用Map進(jìn)行設(shè)計，前半段采用ConcurrentHashMap，后半段采用HashMap，最終其實就是做一個鎖占用標(biāo)記：在某個ResourceId(數(shù)據(jù)庫源ID)上某個Tabel中的某個主鍵對應(yīng)的行記錄的全局寫排它鎖被哪個全局事務(wù)占用。下面，我們來看一下具體獲取鎖的源碼：

如上圖注釋，整個acquireLock邏輯還是很清晰的，對于分支事務(wù)需要的鎖資源，要么是一次性全部成功獲取，要么全部失敗，不存在部分成功部分失敗的情況。通過上面的解釋，可能會有兩個疑問：

為什么鎖結(jié)構(gòu)前半部分采用ConcurrentHashMap,后半部分采用HashMap？

前半部分采用ConcurrentHashMap好理解：為了支持更好的并發(fā)處理；疑問的是后半部分為什么不直接采用ConcurrentHashMap，而采用HashMap呢？可能原因是因為后半部分需要去判斷當(dāng)前全局事務(wù)有沒有占用PK對應(yīng)的鎖資源，是一個復(fù)合操作，即使采用ConcurrentHashMap還是避免不了要使用Synchronized加鎖進(jìn)行判斷，還不如直接使用更輕量級的HashMap。

為什么BranchSession要存儲持有的鎖資源

這個比較簡單，在整個鎖的結(jié)構(gòu)中未體現(xiàn)分支事務(wù)占用了哪些鎖記錄，這樣如果全局事務(wù)提交時，分支事務(wù)怎么去釋放所占用的鎖資源呢？所以在BranchSession保存了分支事務(wù)占用的鎖資源。

下圖展示校驗全局鎖資源能否被獲取邏輯：

下圖展示分支事務(wù)釋放全局鎖資源邏輯

以上就是TC模塊中全局寫排它鎖的實現(xiàn)原理：在分支事務(wù)注冊時，RM會將當(dāng)前分支事務(wù)所需要的鎖資源一并傳遞過來，TC獲取負(fù)責(zé)全局鎖資源的獲取（要么一次性全部成功，要么全部失敗，不存在部分成功部分失敗）；在全局事務(wù)提交時，TC模塊自動將全局事務(wù)下的所有分支事務(wù)持有的鎖資源進(jìn)行釋放；同時，為減少全局寫排它鎖獲取失敗概率，TC模塊對外暴露了校驗鎖資源能否被獲取接口，RM模塊可以在在適當(dāng)位置加以校驗，以減少分支事務(wù)注冊時失敗概率。

二、RM-全局寫排它鎖使用

在RM模塊中，主要使用了TC模塊全局鎖的兩個功能，一個是校驗全局鎖能否被獲取，一個是分支事務(wù)注冊去占用全局鎖，全局鎖釋放跟RM無關(guān)，由TC模塊在全局事務(wù)提交時自動釋放。分支事務(wù)注冊前，都會去做全局鎖狀態(tài)校驗邏輯，以保證分支注冊不會發(fā)生鎖沖突。
在執(zhí)行Update、Insert、Delete語句時，都會在sql執(zhí)行前后生成數(shù)據(jù)快照以組織成UndoLog，而生成快照的方式基本上都是采用Select...For Update形式，RM嘗試校驗全局鎖能否被獲取的邏輯就在執(zhí)行該語句的執(zhí)行器中：SelectForUpdateExecutor，具體如下圖：
?

基本邏輯如下：

執(zhí)行Select ... For update語句，這樣本地事務(wù)就占用了數(shù)據(jù)庫對應(yīng)行鎖，其它本地事務(wù)由于無法搶占本地數(shù)據(jù)庫行鎖，進(jìn)而也不會去搶占全局鎖。

循環(huán)掌握校驗全局鎖能否被獲取，由于全局鎖可能會被先于當(dāng)前的全局事務(wù)獲取，因此需要等之前的全局事務(wù)釋放全局鎖資源；如果這里校驗?zāi)塬@取到全局鎖，那么由于步驟1的原因，在當(dāng)前本地事務(wù)結(jié)束前，其它本地事務(wù)是不會去獲取全局鎖的，進(jìn)而保證了在當(dāng)前本地事務(wù)提交前的分支事務(wù)注冊不會因為全局鎖沖突而失敗。

注：細(xì)心的同學(xué)可能會發(fā)現(xiàn)，對于Update、Delete語句對應(yīng)的UpdateExecutor、DeleteExecutor中會因獲取beforeImage而執(zhí)行Select..For Update語句，進(jìn)而會去校驗全局鎖資源狀態(tài)，而對于Insert語句對應(yīng)的InsertExecutor卻沒有相關(guān)全局鎖校驗邏輯，原因可能是：因為是Insert，那么對應(yīng)插入行PK是新增的，全局鎖資源必定未被占用，進(jìn)而在本地事務(wù)提交前的分支事務(wù)注冊時對應(yīng)的全局鎖資源肯定是能夠獲取得到的。

接下來我們再來看看分支事務(wù)如何提交，對于分支事務(wù)中需要占用的全局鎖資源如何生成和保存的。首先，在執(zhí)行SQL完業(yè)務(wù)SQL后，會根據(jù)beforeImage和afterImage生成UndoLog，與此同時，當(dāng)前本地事務(wù)所需要占用的全局鎖資源標(biāo)識也會一同生成，保存在ContentoionProxy的ConnectionContext中，如下圖所示。

在ContentoionProxy.commit中，分支事務(wù)注冊時會將ConnectionProxy中的context內(nèi)保存的需要占用的全局鎖標(biāo)識一同傳遞給TC進(jìn)行全局鎖的獲取。

以上，就是RM模塊中對全局寫排它鎖的使用邏輯，因在真正執(zhí)行獲取全局鎖資源前會去循環(huán)校驗全局鎖資源狀態(tài)，保證在實際獲取鎖資源時不會因為鎖沖突而失敗，但這樣其實壞處也很明顯：在鎖沖突比較嚴(yán)重時，會增加本地事務(wù)數(shù)據(jù)庫鎖占用時長，進(jìn)而給業(yè)務(wù)接口帶來一定的性能損耗。

三、總結(jié)

本文詳細(xì)介紹了Fescar為在?讀未提交?隔離級別下做到?寫隔離?而實現(xiàn)的全局寫排它鎖，包括TC模塊內(nèi)的全局寫排它鎖的實現(xiàn)原理以及RM模塊內(nèi)如何對全局寫排它鎖的使用邏輯。在了解源碼過程中，筆者也遺留了兩個問題：

全局寫排它鎖數(shù)據(jù)結(jié)構(gòu)保存在內(nèi)存中，如果服務(wù)器重啟/宕機(jī)了怎么辦，即TC模塊的高可用方案是什么呢？

一個Fescar管理的全局事務(wù)和一個非Fescar管理的本地事務(wù)之間發(fā)生鎖沖突怎么辦？具體問題如下圖，問題是：全局事務(wù)A如何回滾？

對于問題1有待繼續(xù)研究；對于問題2目前已有答案，但Fescar目前暫未實現(xiàn)，具體就是全局事務(wù)A回滾時會報錯，全局事務(wù)A內(nèi)的分支事務(wù)A1回滾時會校驗afterImage與當(dāng)前表中對應(yīng)行數(shù)據(jù)是否一致，如果一致才允許回滾，不一致則回滾失敗并報警通知對應(yīng)業(yè)務(wù)方，由業(yè)務(wù)方自行處理。

?

#阿里云開年Hi購季#幸運抽好禮！
點此抽獎：https://www.aliyun.com/acts/product-section-2019/yq-lottery?utm_content=g_1000042901

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的分布式事务中间件 Fescar - 全局写排它锁解读的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。