作者：李海翔，騰訊TEG數據庫技術專家

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

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

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

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

?

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

?

5、3TS 提供的并發訪問控制算法

5.4?樂觀并發控制協議（OCC、FOCC、BOCC）

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

圖5 OCC算法的三個階段圖

這三個階段的劃分，帶來的優勢非常明顯：

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

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

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

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

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

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

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

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

5.4.1 OCC

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

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

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

5.4.2 BOCC

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

5.4.3 FOCC

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

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

?

5.5 優化的樂觀并發控制協議（MaaT、Sundial、Silo）

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

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

5.5.1 MaaT

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

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

1. 讀操作

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

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

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

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

2.?寫操作

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

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

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

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

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

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

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) 協調調整當前事務的lower和before隊列中事務的upper，保證當前事務的lower大于before隊列事務的upper；

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

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

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

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

更新Rts=Max{commit_ts,Rts}；

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

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

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

更新Wts=Max{commit_ts,Wts}。

5.5.2 Sundial

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

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

1.?讀操作

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

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

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

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

2. 寫操作

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

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

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

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

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

3. 驗證階段

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

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

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

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

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

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

4.?寫入階段

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

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

?

5.5.3 Silo

Silo[9]與傳統樂觀并發控制協議的主要區別在驗證階段。其主要思想是驗證自己讀到的數據是否被其他事務修改。因此，事務的驗證流程為：

為所有寫集中的元素對應的數據項加鎖；

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

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

?

5.6 確定性并發控制協議（Calvin）

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

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

Calvin事務執行流程主要包括（假設事務需要使用到Server1和Server2的數據）：

Client將事務發送給Server1節點；

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

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

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

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

Server1向Client返回事務執行完畢。

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

1. ?讀操作：

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

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

2. ?寫操作：

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

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

?

5.7基于快照隔離的并發控制協議（SSI、WSI）

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

5.7.1 SSI

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

5.7.2 WSI

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

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

?

5.8 基于動態時間戳的并發訪問控制算法

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

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

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

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

?

6、3TS 待改進功能

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

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

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

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

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

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

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

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

?

致謝

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

?

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腾讯事务处理技术验证系统(下)的全部內容，希望文章能夠幫你解決所遇到的問題。

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