作者：李海翔，騰訊TEG數(shù)據(jù)庫技術專家

近日，中國人民大學-騰訊協(xié)同創(chuàng)新實驗室正式舉行揭牌儀式。據(jù)了解，雙方已聚焦在數(shù)據(jù)庫基礎研究領域進行了多年的前沿產學研合作，以及數(shù)據(jù)庫人才合作培養(yǎng)計劃，在推進數(shù)據(jù)庫安全可控的同時面向未來大規(guī)模多場景數(shù)字化時代進行前沿創(chuàng)新研究儲備，其中實驗室輸出的包括“全時態(tài)數(shù)據(jù)庫系統(tǒng)”等多項成果相繼被VLDB等國際頂會收錄，同時申請獲得了多項國家技術專利。

在本次實驗室揭牌亮相的同時，騰訊與中國人民大學研究團隊還開源公布了一項最新合作研究成果——3TS騰訊事務處理技術驗證系統(tǒng)。

Tencent Transaction ProcessingTestbed System（簡稱3TS），是騰訊公司TDSQL團隊與中國人民大學數(shù)據(jù)工程與知識工程教育部重點實驗室，聯(lián)合研制的面向數(shù)據(jù)庫事務處理的驗證系統(tǒng)。該系統(tǒng)旨在通過設計和構建事務（包括分布式事務）處理統(tǒng)一框架，并通過框架提供的訪問接口，方便使用者快速構建新的并發(fā)控制算法；通過驗證系統(tǒng)提供的測試床，可以方便用戶根據(jù)應用場景的需要，對目前主流的并發(fā)控制算法在相同的測試環(huán)境下進行公平的性能比較，選擇一種最佳的并發(fā)控制算法。目前，驗證系統(tǒng)已集成13種主流的并發(fā)控制算法，提供了TPC-C、Sysbench、YCSB等常見基準測試。3TS還進一步提供了一致性級別的測試基準，針對現(xiàn)階段分布式數(shù)據(jù)庫系統(tǒng)的井噴式發(fā)展而造成的系統(tǒng)選擇難問題，提供一致性級別判別與性能測試比較。

3TS系統(tǒng)旨在深度探索數(shù)據(jù)庫事務處理相關理論與實現(xiàn)技術，其核心理念是：開放、深度、進化。開放，秉承開源之心，共享知識、共享技術；深度，踐行系統(tǒng)化鉆研之精神，對于事務處理技術的本質問題進行研究，不破樓蘭終不還；進化，路漫漫其修遠兮，吾將上下而求索，不斷前行，不斷推進。

?

在上一個章節(jié)文章中，我們介紹了3TS的框架和基礎內容（詳情訪問《騰訊與中國人民大學開源最新研究成果：3TS騰訊事務處理技術驗證系統(tǒng)》），本章節(jié)繼續(xù)深入介紹多種并發(fā)訪問控制算法。

?

5、3TS 提供的并發(fā)訪問控制算法

5.4?樂觀并發(fā)控制協(xié)議（OCC、FOCC、BOCC）

在樂觀并發(fā)控制協(xié)議下，事務的執(zhí)行流程被分成三個階段：讀取、驗證、寫入階段[5]，如圖5所示。

圖5 OCC算法的三個階段圖

這三個階段的劃分，帶來的優(yōu)勢非常明顯：

事務處理性能高：事務的效率的提升主要是依靠第一階段通過讀寫互不阻塞來保證的，這極大提高了讀寫、寫讀這兩種情況的并發(fā)度，多核的硬件資源能夠得到充分利用；并且對于只讀事務因不被阻塞而倍顯友好。

可避免死鎖問題：OCC可以在第一階段通過對讀寫對象排序、第二階段按序加鎖可避免死鎖。這在與封鎖并發(fā)訪問控制算法對死鎖問題解決的對比下獲勝。這兩點優(yōu)勢使得OCC在處理分布式事務、高數(shù)據(jù)熱點、高通信延時等場景下依然能夠支持高事務吞吐率，在高并發(fā)場景下沒有明顯的系統(tǒng)性能抖動現(xiàn)象（文獻[169]通過實驗表明高競爭下OCC算法性能不高）。

數(shù)據(jù)一致性的正確性得到保證：正確性是在第二階段驗證階段保證的，其原理是通過事務沖突關系構造有向圖檢測是否存在有環(huán)的情況而通過回滾某個事務破除環(huán)的存在，達到解決事務沖突的目的；而寫寫沖突是在驗證階段通常通過封鎖機制保證。但工程實現(xiàn)，有不同的方式，如文獻[9]改進了OCC算法，在驗證階段檢查本事務的讀集如果被其他并發(fā)事務寫過即觸發(fā)回滾以避免數(shù)據(jù)不一致，從而不用構造有向圖檢測是否存在有環(huán)存在。

3TS中，根據(jù)驗證機制的不同，實現(xiàn)了三個不同的樂觀并發(fā)控制協(xié)議：（1）OCC：對[5]中的ParallelValidation算法的實現(xiàn)；（2）BOCC：對[6]中的Backward Validation算法的實現(xiàn)；（3）FOCC：對[6]中的Forward Validation算法的實現(xiàn)。需要注意的是，3TS中，由于沒有全局時間戳機制（后續(xù)計劃會增加全局時鐘），驗證階段需要對比的讀寫集大小可能由于時鐘不同步產生偏差，因此可能會對不同算法的效率產生不同程度的影響。

1. 三個協(xié)議對讀取階段的處理是相同的，主要為：

a)?讀操作時，先把讀操作存入讀集，并按要求讀到所需要的數(shù)據(jù)；

b) 寫操作時，把寫操作寫入寫集

2. 驗證階段，三個協(xié)議的主要思想都是保證事務按照進入驗證的順序進行排序，通過檢查讀寫集保證事務的操作結果滿足進入驗證的先后順序。不同協(xié)議的檢查讀寫集的方法存在不同。

5.4.1 OCC

驗證操作的主要流程為（當前待驗證事務的開始時間戳記為start_ts，進入驗證的時間戳記為finish_ts）：

a)?獲取在(start_ts,finish_ts]這一時間段內的提交的事務集合，記為History，遍歷History中事務的寫集，如果與當前事務的讀集存在交集，則當前事務驗證失敗；

b)?獲取處在驗證階段的事務集合，記為Active，檢查集合中事務的寫集和當前事務的讀集是否存在交集，如果存在，則驗證失敗；

5.4.2 BOCC

要求驗證階段和寫入階段在同一個臨界區(qū)中執(zhí)行，流程為獲取在(start_ts,finish_ts]這一時間段內的提交的事務集合，記為History，遍歷History中事務的寫集，如果與當前事務的讀集存在交集，則當前事務驗證失敗。BOCC具有比較明顯的缺點，包括只讀事務也需要進行驗證、待驗證事務的讀集較大時對驗證效率影響較大，對于長事務需要保留大量期間已提交事務的寫集等。

5.4.3 FOCC

要求驗證階段和寫入階段在同一個臨界區(qū)中執(zhí)行，檢查待驗證事務的寫集是否與當前活躍（正在讀寫階段）事務的讀集如果存在有交集，則當前事務驗證階段。FOCC較BOCC具有只讀事務可以跳過驗證階段，與活躍事務進行驗證開銷較小的優(yōu)點。

3. 三個協(xié)議對寫入階段的處理是相同的，主要為：獲取提交時間戳，將寫集中數(shù)據(jù)寫入數(shù)據(jù)庫，并設置數(shù)據(jù)的提交時間戳為獲取到的提交時間戳。

?

5.5 優(yōu)化的樂觀并發(fā)控制協(xié)議（MaaT、Sundial、Silo）

傳統(tǒng)的樂觀并發(fā)控制協(xié)議依照進入驗證的順序來確定事務是否可以提交，與傳統(tǒng)的OCC相比，一些優(yōu)化的樂觀并發(fā)控制協(xié)議通過放寬這一要求，減少了不必要回滾?，F(xiàn)在，基于OCC的改進版本有很多，如ROCC[20]、自適應OCC[21]等。

在3TS中，我們集成了三種較新的樂觀并發(fā)控制算法，包括MaaT、Sunidal和Silo。期待有更多的并發(fā)算法集成到3TS中。

5.5.1 MaaT

MaaT[6]采用了動態(tài)時間戳范圍調整的方式來降低事務回滾率。其主要思想是通過事務間的讀寫操作之間形成的關系，確定事務的先后順序，從而確定可串行化要求的等價串行序列中事務的先后順序。例如，Ti事務讀x之后，Tj事務需要更新x，則在等價串行序列中，Ti需要排在Tj的前面。

MaaT需要在每個數(shù)據(jù)項上額外維護元數(shù)據(jù)，包括：（1）記錄讀了該數(shù)據(jù)項但仍未提交的事務ID，稱為讀事務列表readers；（2）記錄要寫該數(shù)據(jù)項但仍未提交的事務ID，稱為寫事務列表writers；（3）讀過該數(shù)據(jù)項的事務中最大的提交時間戳，記為Rts；（4）寫過該數(shù)據(jù)項的事務中最大的提交時間戳，記為wts。每個事務會有一個時間戳范圍[lower,upper)，并初始化為[0,+)。事務中的各個操作的流程主要包括：

1. 讀操作

a)?將數(shù)據(jù)項的寫事務列表存入事務的uncommitted_writes；

b)?更新當前事務的greatest_write_timestamp=Max{greatest_write_timestamp,wts}；

c)?將當前事務ID寫入所讀數(shù)據(jù)項的讀事務列表；

d)?讀對應數(shù)據(jù)項，并將讀到的數(shù)據(jù)存入讀集。

2.?寫操作

a)?將數(shù)據(jù)項的寫事務列表存入事務的uncommitted_writes_y。

b)?將數(shù)據(jù)項的讀事務列表存入事務的uncommitted_reads。

c)?更新當前事務的greatest_write_timestamp=Max{greatest_write_timestamp,wts}，greatest_read_timestamp=Max{greatest_red_timestamp,rts}；

d) 將當前事務ID寫入要寫數(shù)據(jù)項的寫事務列表；

e)?將要寫的數(shù)據(jù)項新值存入寫集；

3.?驗證階段（事務協(xié)調者根據(jù)所有參與者返回的lower和upper取交集確定lower和upper，如下操作均在參與者上執(zhí)行）:

a)?更新lower=Max{greatest_write_timestamp+1,lower}；

b)?保證uncommitted_writes（未提交寫事務列表）中事務的lower大于當前事務的upper；

如果uncommitted_writes中的事務已經驗證通過，修改當前事務的upper；

否則將uncommitted_writes中的事務放進當前事務的after隊列（隊列中的事務需要在當前事務之后提交）；

c)?更新lower=Max{greatest_read_timestamp+1,lower}；

d) 保證uncommitted_reads（未提交讀事務列表）中事務的upper小于當前事務的lower；

如果uncommitted_reads中的事務已經驗證通過，修改當前事務的lower；

否則將列表中的事務放進當前事務的before隊列（隊列中的事務需要在當前事務之前提交）；

e) 調整uncommitted_writes_y（存在寫寫沖突的未提交事務列表）和當前事務的先后關系；

如果uncommitted_writes_y中的事務已經驗證通過，修改當前事務的lower大于列表中已驗證通過事務的upper；

否則將列表中的事務事務放進當前事務after隊列；

f) 檢查lower<upper是否成立，不成立則回滾當前事務；

g) 協(xié)調調整當前事務的lower和before隊列中事務的upper，保證當前事務的lower大于before隊列事務的upper；

h)?協(xié)調調整當前事務的upper和after隊列中事務的lower，保證當前事務的upper小于after隊列中事務的lower；

4.?寫入階段（首先在協(xié)調者上確定提交時間戳（commit_ts）為最終時間戳區(qū)間的lower，然后在參與者上執(zhí)行如下操作）

a)?對于讀集中的每個元素，將當前事務從對應數(shù)據(jù)項的讀事務列表中清除，并進行如下操作：

保證寫事務列表中事務的lower大于當前事務的commit_ts；

更新Rts=Max{commit_ts,Rts}；

b)?對于寫集中的每個元素，將當前事務從對應數(shù)據(jù)項的寫事務列表中清除，并進行如下操作：

保證寫事務列表中事務的upper小于當前事務的commit_ts。

保證讀事務列表中事務的upper小于當前事務的commit_ts。

更新Wts=Max{commit_ts,Wts}。

5.5.2 Sundial

Sundial[8]通過動態(tài)計算提交時間戳以減少回滾率。同時在數(shù)據(jù)項上維護租約（即數(shù)據(jù)項的可以被訪問到的邏輯時間范圍），便于在發(fā)生沖突時快速確定事務的先后順序。此外Sundial在樂觀并發(fā)控制的基礎上，結合了悲觀并發(fā)控制的思路，讀寫/寫讀沖突用OCC、寫寫沖突用2PL鎖的方式來減少分布式事務協(xié)調調度的開銷。

Sundial在數(shù)據(jù)項上維護租約(wts,rts)，分別代表了數(shù)據(jù)項最后被寫入的時間和數(shù)據(jù)項可以被讀到的最晚時間。在事務上維護commit_ts，代表事務的提交時間戳。在讀寫集中額外維護orig.rts和orig.wts，代表訪問數(shù)據(jù)項當時的rts和wts。我們對Sundial的主要操作的執(zhí)行流程介紹如下：

1.?讀操作

a)?首先從讀寫集中讀取所需要的數(shù)據(jù)項，如果讀寫集中不存在所需數(shù)據(jù)項

則需要訪問數(shù)據(jù)存儲，找到對應數(shù)據(jù)項并讀取，并記錄此時數(shù)據(jù)項的wts和rts，記為orig.wts和orig.rts；

更新當前事務的commit_ts=max{orig.wts,commit_ts}；

b)?? 如果讀寫集中存在所需數(shù)據(jù)，直接返回對應數(shù)據(jù)；

2. 寫操作

a)?首先從寫集中找到所要修改的數(shù)據(jù)項，如果寫集中不存在所需數(shù)據(jù)項

對元組加鎖，若加鎖失敗，存入等待隊列waiting_set；

否則，直接返回數(shù)據(jù)項，以及對應的wts和rts，記為orig.wts和orig.rts；

b)?如果讀寫集中存在當前待更新的數(shù)據(jù)項對應元素，則在寫集中對其進行更新；

c)?更新當前事務的commit_ts=max{orig.rts,commit_ts}；

3. 驗證階段

a)?首先計算出提交時間戳commit_ts，主要通過如下兩步（該步驟為3TS中實現(xiàn)新增，由于讀寫操作在參與者上進行，協(xié)調者在進入驗證前需要匯總所有參與者的信息得到commit_ts）：

遍歷寫集，更新commit_ts大于等于寫集中所有元素的orig.rts；

遍歷讀集，更新commit_ts大于等于讀集的orig.wts；

b)?驗證讀集中的每一個元素：

如果提交時間戳commit_ts小于rts，跳過當前元素；

嘗試更新元組租約：（1）如果orig.wts！=wts，即當時讀取的wts和元組現(xiàn)在的wts不同，當前事務需要回滾；（2）如果當前元組被加了鎖，當前事務回滾；（3）否則更新元組的rts=Max{rts,commit_ts}；

4.?寫入階段

a)?提交操作，對寫集中元素對應的數(shù)據(jù)項更新并解鎖；

b)?回滾操作，對寫集中元素對應的數(shù)據(jù)項解鎖。

?

5.5.3 Silo

Silo[9]與傳統(tǒng)樂觀并發(fā)控制協(xié)議的主要區(qū)別在驗證階段。其主要思想是驗證自己讀到的數(shù)據(jù)是否被其他事務修改。因此，事務的驗證流程為：

為所有寫集中的元素對應的數(shù)據(jù)項加鎖；

驗證讀集中的數(shù)據(jù)：（1）被別的事務修改或（2）由別的事務加鎖。如果存在兩種情況中的一種，則當前事務回滾；

獲得提交時間戳并進入寫入階段。

?

5.6 確定性并發(fā)控制協(xié)議（Calvin）

Calvin[10]的主要思想是提前確定好事務的順序，之后事務則會嚴格按照確定的順序進行執(zhí)行。避免了其他并發(fā)控制協(xié)議所需的分布式協(xié)調開銷。

Calvin算法需要增加兩個模塊：定序器（Sequencer）和調度器（Scheduler）。其中定序器用于攔截事務并且為這些事務規(guī)定順序（順序就是事務進入定序器的順序），調度器負責按照定序器給定的順序執(zhí)行事務。

Calvin事務執(zhí)行流程主要包括（假設事務需要使用到Server1和Server2的數(shù)據(jù)）：

Client將事務發(fā)送給Server1節(jié)點；

Server1的定序器接受到事務，將事務放入一個batch中；

經過batch規(guī)定的時間后，定序器將包含事務的batch發(fā)送給事務對應的兩個參與者節(jié)點Server1和Server2的調度器上；

Server1和Server2的調度器接收到batch，根據(jù)batch事先規(guī)定的順序進行加鎖。之后將batch中的事務放入WorkThread(工作線程)中執(zhí)行；

Server1和Server2執(zhí)行完畢batch中的所有事務后，將返回消息發(fā)送給Server1；

Server1向Client返回事務執(zhí)行完畢。

事務執(zhí)行時的加鎖機制依然遵循2PL的邏輯，主要包括：

1. ?讀操作：

a)? 檢查數(shù)據(jù)項上是否存在排它鎖，檢查數(shù)據(jù)項的waiters列表是否為空。若不存在排他鎖且waiters列表為空，則讀取對應數(shù)據(jù)項，并將當前事務放入owner；

b)??否則，加鎖存在沖突，將當前事務存入waiters等待事務列表；

2. ?寫操作：

a)??檢查數(shù)據(jù)項上是否存在鎖，檢查數(shù)據(jù)項的waiters事務是否存在。若不存在排他鎖且waiters列表為空，將當前事務放入owner；

b)??否則，加鎖存在沖突，將當前事務存入waiters等待事務列表。

?

5.7基于快照隔離的并發(fā)控制協(xié)議（SSI、WSI）

快照隔離（Snapshot Isolation, SI）[11]主要對同一數(shù)據(jù)項上的寫寫沖突和寫讀沖突進行了約束。對于寫寫沖突，其規(guī)定，數(shù)據(jù)項不能同時被兩個事務并發(fā)修改，另外遵循“先提交者獲勝策略”，先提交的寫事務將會成功，另一個事務將會回滾。對于寫讀沖突，其規(guī)定事務只能讀取最新已提交的數(shù)據(jù)項版本，即讀取事務開始時符合一致性狀態(tài)的數(shù)據(jù)。因此，其具有讀寫互不阻塞的事務處理特性。SI機制本身不能做到可串行化，因此在SI基礎上實現(xiàn)可串行化，需要引入額外的操作。在3TS中，實現(xiàn)了兩種主流的可串行化快照隔離機制：（1）SSI：Serializable Snapshot Isolation；（2）WSI：Write SnapshotIsolation。

5.7.1 SSI

如果事務Ti讀了x，事務Tj寫入了一個x的新版本，那么我們稱Ti讀寫依賴于Tj。SSI[12,13]通過理論證明，發(fā)現(xiàn)要在SI基礎上做到可串行化，只需要禁止Ti讀寫依賴于Tj，且Tk讀寫依賴于Ti這種情況即可。算法的核心就在于動態(tài)檢測出這種情況，因此會在每個事務記錄inConflict和outConflict兩個字段：inConflict記錄了讀寫依賴于當前事務的事務，outConflict記錄了當前事務讀寫依賴的事務。當發(fā)現(xiàn)當前事務這兩個字段都不為空時，則立刻回滾當前事務，從而保證了可串行化。

5.7.2 WSI

WSI[14]通過將寫寫沖突的檢測轉化為讀寫沖突的檢測，并避免讀寫沖突來做到可串行化。

對于每個事務，WSI需要維護它的讀集和寫集。為了避免幻象，對于范圍查詢讀集里放的是查詢謂詞。對于每一個記錄需要維護last commit時間戳，每當事務提交會更新所有修改過的行的last commit時間戳為事務的提交時間戳。事務提交前的檢查如下：檢查所有讀集中元素對應的數(shù)據(jù)項，如果它的last commit時間戳大于當前事務的start timestamp（消除了讀寫沖突），就回滾當前事務。

?

5.8 基于動態(tài)時間戳的并發(fā)訪問控制算法

第五點，我們介紹了一些OCC的改進算法，其中提及的MaaT、Sundial，是在利用了OCC的框架，結合TO算法進行改進的一種方式。但是，他們又不只是基于TO，傳統(tǒng)的TO算法是一種靜態(tài)的算法，時間戳是確定的、剛性的。而MaaT、Sundial以及Tictoc[22]等，采用的是動態(tài)時間戳分配算法。這樣把OCC框架（策略）的優(yōu)勢、動態(tài)時間戳的優(yōu)勢結合起來。

動態(tài)時間戳分配（dynamictimestamp allocation，簡稱DTA），最先在文獻[23]中提出，之后被多篇文獻引用和應用。此算法的核心思想：是不依賴中心化的時間戳機制、根據(jù)數(shù)據(jù)項上的并發(fā)事務沖突關系、通過動態(tài)調整數(shù)據(jù)項上的事務的執(zhí)行時間段，來實現(xiàn)全局事務的可串行化。該算法避免一些在非動態(tài)時間戳分配算法下被認為是存在沖突而被回滾的情況。

文獻[22]介紹了一種名為“Time Traveling Optimistic Concurrency Control（TicToc）”的算法，該算法基于OCC算法，提出“data-driven timestamp management”的思路，即不給每個事務分配獨立的（全局）時間戳，而是在訪問數(shù)據(jù)項時嵌入必要的（本地）時間戳信息，用于為每個事務在提交之前計算出有效的提交時間戳，而經計算（不是預先分配）而得的提交時間戳用于解決并發(fā)沖突從而保證事務是可串行化的。因不用在分布式事務開始和提交階段依賴全局的協(xié)調器為事務分配時間戳，所以在這個階段，可實現(xiàn)去中心化的目的。因結合使用OCC機制，所以可縮小事務沖突重疊的執(zhí)行時間段，提高了并發(fā)度。

文獻[7]基于OCC框架，實現(xiàn)了DTA算法，即前述的MaaT算法（第5.5節(jié)），這里不再展開。

?

6、3TS 待改進功能

3TS系統(tǒng)提供了統(tǒng)一的技術研制平臺，可以對多種并發(fā)訪問控制算法進行統(tǒng)一對比、分析。目前仍然存在如下待改進的地方，會對不同并發(fā)控制協(xié)議帶來不同程度的影響，影響實驗結果的準確性。我們主要總結了如下待改進的功能點：

消息通信機制，可以考慮通過RPC等方式替代現(xiàn)有的消息通信機制，從而減少消息隊列中的等待對事務性能的影響。

線程調度模型（一個線程綁定一個核），可以考慮引入更多的調度模型，幫助分析線程調度方法對并發(fā)控制協(xié)議性能的影響。

不支持SQL語句，需要引入SQL解析等操作，來更好的模擬真實數(shù)據(jù)庫場景。

不支持全部的TPCC事務，需要進一步引入Delivery等事務類型，從而支持全部的TPCC測試。

全局時間，沒有全局時間戳生成模塊，使用機器本地的時間戳可能會存在時鐘偏差，對OCC等協(xié)議造成影響。

死鎖檢測算法，可以考慮引入死鎖檢測算法，來更好的分析其他的2PL協(xié)議。

Deneva中各個算法不可以動態(tài)切換，每種算法使用宏（C語言的宏）來進行切換，這要求系統(tǒng)切換算法執(zhí)行時，每次都要動態(tài)編譯后再運行，這是一個待改進點。

?

致謝

感謝騰訊CynosDB（TDSQL）團隊與中國人民大學數(shù)據(jù)工程與知識工程教育部重點實驗室對本項工作的支持，感謝趙展浩，劉暢，趙泓堯等同學為本文做出貢獻。

?

Reference

[1] Rachael Harding, Dana Van Aken, Andrew Pavlo, Michael Stonebraker: AnEvaluation of Distributed Concurrency Control. Proc. VLDB Endow. 10(5): 553-564(2017)

[2] ??? Philip A. Bernstein, NathanGoodman: Concurrency Control in Distributed Database Systems. ACM Comput. Surv.13(2): 185-221 (1981)

[3] Daniel J. Rosenkrantz, Richard Edwin Stearns, Philip M. Lewis II:System Level Concurrency Control for Distributed Database Systems. ACM Trans.Database Syst. 3(2): 178-198 (1978)

[4] D. P. Reed. Naming and synchronization in a decentralized computersystem. PhD thesis, Massachusetts Institute of Technology, Cambridge, MA, USA,1978.

[5] H. T. Kung, John T. Robinson: On Optimistic Methods for ConcurrencyControl. ACM Trans. Database Syst. 6(2): 213-226 (1981)

[6] Theo H?rder: Observations on optimistic concurrency control schemes.Inf. Syst. 9(2): 111-120 (1984)

[7] Hatem A. Mahmoud, Vaibhav Arora, Faisal Nawab, Divyakant Agrawal, AmrEl Abbadi: MaaT: Effective and scalable coordination of distributedtransactions in the cloud. Proc. VLDB Endow. 7(5): 329-340 (2014)

[8] Xiangyao Yu, Yu Xia, Andrew Pavlo, Daniel Sánchez, LarryRudolph, Srinivas Devadas:

Sundial: Harmonizing Concurrency Control and Caching in a Distributed OLTPDatabase Management System. Proc. VLDB Endow. 11(10): 1289-1302 (2018)

[9] Stephen Tu, Wenting Zheng, Eddie Kohler, Barbara Liskov, Samuel Madden:Speedy transactions in multicore in-memory databases. SOSP 2013: 18-32

[10] Alexander Thomson, Thaddeus Diamond, Shu-Chun Weng, Kun Ren, PhilipShao, Daniel J. Abadi: Calvin: fast distributed transactions for partitioneddatabase systems. SIGMOD Conference 2012: 1-12

[11] Hal Berenson, Philip A. Bernstein, Jim Gray, Jim Melton, Elizabeth J.O'Neil, Patrick E. O'Neil: A Critique of ANSI SQL Isolation Levels. SIGMODConference 1995: 1-10

[12] Alan D. Fekete, Dimitrios Liarokapis, Elizabeth J. O'Neil, Patrick E.O'Neil, Dennis E. Shasha: Making snapshot isolation serializable. ACM Trans.Database Syst. 30(2): 492-528 (2005)

[13] Michael J. Cahill, Uwe R?hm, Alan D. Fekete: Serializable isolationfor snapshot databases. SIGMOD Conference 2008: 729-738

[14] Maysam Yabandeh, Daniel Gómez Ferro: A critique of snapshotisolation. EuroSys 2012: 155-168

[15] https://en.wikipedia.org/wiki/Distributed_transaction

[16] P. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control andRecovery in Database Systems. Addison–Wesley, 1987.

[17] D. R. Ports and K. Grittner, “Serializable snapshot isolation inpostgresql,” PVLDB, vol. 5, no. 12, pp. 1850–1861, 2012.

[18] J.B?ttcher, et al., ScalableGarbage Collection for In-Memory MVCC Systems, in?VLDB,2019

[19] Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, Andrew Pavlo:An EmpiricalEvaluation of In-Memory Multi-Version Concurrency Control. Proc. VLDBEndow. 10(7): 781-792 (2017)

[20] D. Lomet and M. F. Mokbel, “Locking key ranges with unbundledtransaction services,” VLDB, pp. 265–276, 2009.

[21] Jinwei Guo, Peng Cai, Jiahao Wang, Weining Qian, Aoying Zhou:Adaptive Optimistic Concurrency Control for Heterogeneous Workloads. PVLDB12(5): 584-596 (2019)

[22] X. Yu, A. avlo, D. Sanchez, and S.Devadas, “Tictoc: Time traveling optimistic concurrency control,” in Proceedingsof SIGMOD, vol. 8, 2016, pp. 209–220.

[23] Rudolf Bayer,Klaus Elhardt, Johannes Heigert, Angelika Reiser:Dynamic Timestamp Allocation forTransactions in Database Systems. DDB 1982: 9-20

總結

以上是生活随笔為你收集整理的最新开源：3TS腾讯事务处理技术验证系统(下)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。