騰訊TBase是一款騰訊自研高效能HTAP資料庫，提供 高效能的OLTP和OLAP能力，同時保證 可擴充套件全域性一致性分散式事務(ACID)，為使用者提供高一致性的分散式資料庫服務和高效能的資料倉儲服務。一方面解決了傳統資料庫擴充套件不足、資料sharding之後資料庫事務的嚴格一致性難題、資料安全、跨地域容災等問題，同時具備了高效能事務處理、資料治理、混合負載支援等能力。

在OLTP方面，TBase採用 MVCC+全域性時鐘+2PC+SSI的方式來實現全域性一致性分散式事務，同時引入大量效能優化的設計來減少全域性事務帶來的開銷。在小規模叢集上，TBase能夠提供超過300萬TPMTotal的事務處理吞吐量(工業界標準TPCC測試集)。

交易毫秒內完成

TBase已經覆蓋多個行業的標杆使用者，其中對內支援了微信廣告、微信支付、騰訊地圖等海量資料業務，一筆交易毫秒內即可完成，支撐了微信支付50倍的交易增長。

本文先介紹TBase的架構體系和資料庫事務的基本原理，然後介紹學術界最先進的分散式事務設計方案，最後闡述我們的設計原理。

全文12000字，預計閱讀時間：30分鐘。

TBase騰訊自研高效能HTAP資料庫介紹

—— TBase整體系統架構圖 ——

TBase是一款騰訊自研高效能HTAP分散式資料庫，同時提供高效能的OLTP和OLAP能力，整體系統架構如上圖所示。具體的，TBase由多個協調節點(Coordinator)，多個資料節點(Data Node)和單個時鐘伺服器(GTS)組成。使用者表資料採用shard機制 [9,12]在多個Data Node進行分佈。Coordinator節點負載接受使用者的SQL請求，解析SQL生成分散式執行計劃，然後在Data Node上分配資源執行該分散式執行計劃。每個Data Node執行著完整的資料庫例項，包括儲存層，日誌層，事務處理層，查詢優化器，執行器等。GTS負責生成嚴格遞增的時間戳，用於保證全域性一致性分散式事務。

資料庫事務機制

資料庫事務ACID是關係型資料庫最基本和最核心的一個特性。資料庫事務提供給使用者一個強大的抽象概念，能夠簡化上層應用儲存和訪問資料的邏輯。比如資料庫事務的最嚴格的Serailizable隔離級別可以保證併發的事務的執行效果和序列執行這些事務的效果是一樣的，從而使得上層應用不需要考慮複雜的併發導致的一致性問題。資料庫事務的 原子性(A)，一致性(C)和永續性(D)基本都是通過WAL(Write-ahead Log)日誌來實現，在分散式場景下還需要引入額外的兩階段提交(2PC)來保證，這裡就不詳細闡述。 本文重點介紹事務裡面最複雜的隔離性(I)。

我們首先介紹一下 資料庫隔離語義： read committed，repeatable read 和serializable。

所有的隔離級別語義都需要滿足： 事務T1能夠看到T2的修改，當前僅當T1.start > T2.commit。T1.start為T1事務開始的絕對時間，T2.commit為T2提交的時間。對於read committed，即T1.start為每條語句開始時間。

Read committed：滿足上述的語義的同時，對於寫寫衝突， 採取允許並行修改的策略，從而減少abort。具體的，對於一個tuple， T1(x, w)寫入x值，T2(y, w)寫入y值，如果T1先提交，則該值變為x，T2再提交時，將改成y。如果update語句中有where判斷條件，T2會重新計算更新的最新值x是否滿足條件，再進行更新。

Repeatable read: 對於寫寫衝突， 採用First-commit-win機制，並行修改事務第一個提交的將成功，後面提交的將被abort。Repeatable read和read committed都會存在write skew的問題 [1,2]。考慮如下併發執行，T1執行讀取x，然後將x值寫入y，T2執行讀取 y，然後將y值寫入x。在Repeatable read隔離下，T1和T2均可以提交成功，但是執行結果不滿足序列化執行T1和T2後的結果，即先執行T1再執行T2，或反過來。

Serializable：在Repeatble read隔離基礎上，如果兩個事務T1和T2 存在讀寫依賴(rw-dependency)，也會abort後提交的事務。 Serializable隔離級別執行結果滿足並行事務任意序列化執行的結果。即例如T1和T2並行執行，最後的結果滿足任意序列化執行(T1->T2或者T2->T1)的結果。這種隔離級別執行結果最容易被使用者理解，對使用資料庫的應用程式來說，可以極大的簡化上層業務邏輯(不用去考慮並行)，但是會導致比較頻繁的abort(在衝突比較大的時候)。

資料庫實現上述隔離級別主要有 三種主流的方法: 2PL,OCC和MVCC。

2.1 2PL (Two-phase Locking)

兩階段鎖，是一種最簡單又最低效的實現事務隔離的方法。2PL通過在事務開始階段對所有訪問資料物件進行加鎖，在事務結束的時候進行解鎖，來序列化並行事務的執行，從而實現Serializable隔離級別。該方法會導致 極低的執行併發度。

2.2 OCC (Optimistic Concurrency Control)

OCC採用 兩階段執行(execution phase和 commit phase)來提供事務隔離。

執行階段：每個事務將writes快取在本地write-set(對其它事務不可見)，同時記錄讀操作到read-set(讀的位置和序列號)。訪問一個記錄的時候，如果該記錄被鎖住(其它事務提交階段鎖)，則選擇abort。

提交階段：該階段將對write-set中的記錄進行加鎖，並檢查讀的記錄(read-set一定包含write-set，因為修改一個記錄需要先讀一個記錄，即read before write)在事務執行過程中是否被其它併發事務所修改(檢查序列號)，如果被修改，則abort本事務。如果沒有被修改，則將write-set中的資料寫入資料庫儲存，更新序列號，最後解鎖。OCC可以提供Serializable隔離保證，但是讀寫衝突情況下，讀併發低(很多負載是read-dominated的負載，改進讀效能很重要)。

2.3 MVCC (Multi-Vesion Concurrency Control)

MVCC通過多版本來提供更高的讀併發，同時通過snapshot isolation機制保證read-committed和read-repeatable隔離級別(相比serializable隔離級別弱)。 MVCC的基本原理是通過多版本鏈來在併發寫的情況下支援non-blocking讀。MVCC可以保證併發更新的同時，併發讀可以讀到事務開始前(或者語句開始前)的一致性的資料庫快照。

MVCC具體的實現方法是每個tuple(表的每個邏輯行對應的物理儲存單元)都有一個xmin和xmax，xmin表示插入該tuple的事務xid，xmax表示刪除該tuple的事務xid。Update操作由一個刪除和插入組成。每個表的邏輯行由一串多版本的tuple鏈組成。每個事務開始前獲取一個系統範圍內正在執行的事務的xid集合(資料庫快照)，在訪問某個邏輯行時，對它的版本tuple鏈進行遍歷，從而找到對該事務可見的最新版本(即會拿xmin和xmax在快照中進行查詢判斷，讀取事務開始之前已經提交的最新的tuple版本)。

快照判斷的原理是，如果一個xid在快照中，說明插入這個tuple的事務在當前事務開始時正在執行中，則這個事務xid的修改對當前事務不可見。否則，當前事務進一步判斷xid是否已經提交，如果已經提交(並且不在快照中)，則該xid的修改對當前事務可見。

在一定的時候，空間回收程式對老的版本進行 空間回收(熱回收和冷回收)，來釋放空間，更重要的是減少版本鏈的長度(減少讀搜尋可見版本的開銷)。 熱回收是在掃描的時候開啟，用來將每個掃描的頁面上的多版本進行compact從而減少搜尋長度，來加速後面的掃描。 冷回收是專門的程式執行，對錶進行空間回收，即將頁面上有效的tuple版本拷貝到新的頁面上去，從而徹底回收空間。

空間回收有一個挑戰是要 判斷哪些版本可以回收，從而避免回收掉正在(即將)被訪問的記錄。一個基本的演算法(PostgreSQL裡的演算法)是計算整個系統範圍內所有事務可見的最老的xid，然後回收xid < oldestxmin的事務插入後來被刪除(或者更新)的記錄。

Oldestxmin演算法：在生成快照的時候，以系統範圍內完成的最大的xid + 1為oldestxmin，然後更新oldestxmin小於或等於每個正在執行事務的xid，並且小於或等於每個事務生成快照時它計算出的oldestxmin。這樣對於每個邏輯行，回收xmax < oldestxmin的tuple版本可以保證正在執行的事務一定可以看到對它可見的一個版本，即回收的版本不會被其它事務訪問(不可見)。

—— MVCC多版本鏈和空間回收機制 ——

上圖展示了MVCC的基本原理。表的某個邏輯行有三個版本<xid1, xid2>，<xid2, xid3>和<xid3, invalid>，tuple的data部分被省略。Invalid表示是最後一個版本，每個刪除或者更新會將invalid欄位修改成該事務的xid，再插入一個新的版本(更新)。該邏輯行由xid1事務插入，並依次被事務xid2和xid3更新。假設有一個和xid3並行執行的讀事務T1，則xid3在事務T1的快照中，T1進行掃描的時候，發現xid1和xid2均已經提交併且不在快照中，<xid1,xid2>對T1不可見，繼續遍歷下一個版本時，發現xid3在快照中，xid2不在並且已經提交，因此T1會讀取該邏輯行的第二個版本<xid2, xid3>，從而在更新(xid3)的同時支援無阻塞的讀(T1)。T1讀取的是它開始時資料庫的快照<xid2, xid3>。

同時，我們考慮空間回收機制，假設計算出來的oldesetxmin滿足xid2 < oldestxmin < xid3，則空間回收程式會將該邏輯行的第一個版本進行回收，從而回收空間(冷回收)或者減少頁面中版本鏈的長度(熱回收)。

我們用反證法證明oldestxmin回收演算法是正確的。

證明：

回收事務為T1(xid2 < T1.oldestxmin <= xid3)，假設被回收的版本<xid1, xid2>對當前正在執行的某個事務T2可見，則必須滿足對T2來說xid1不在快照中，xid2在T2的快照中。由於xid2在T2的快照中，則必然滿足xid2 >= T2.oldestxmin，從而T1.oldestxmin > xid2 >= T2.oldestxmin(不等式1)。由T1.oldestxmin > T2.oldestxmin可以匯出T1生成oldestxmin發生在T2之後。由oldestxmin生成演算法可知，T1一定會讀取到T2的oldestxmin，並且將T1的oldestxmin更新為小於或等於T2的oldestxmin，即T1.oldestxmin <= T2.oldestxmin，這與不等式1矛盾。

因此，假設不成立。根據oldestxmin回收的版本<xid1, xid2>對當前正在執行的任意事務均不可見，執行事務會去讀取下一個可見版本，即<xid2, xid3>或者<xid3, invalid>。

對於任意即將開啟的事務T3,由於xid2 < T1.oldestxmin, 則xid2一定不會出現在T3的快照中，<xid1, xid2>這個被回收的版本對T3也不可見。 證畢。

MVCC機制提供的snapshot isolation可以保證read committed和repeatable read兩種隔離級別，但是沒法保證Serailizable隔離級別。SSI技術是在MVCC的基於快照隔離機制上通過track併發事務之間的rw-dependency來提供Serializable隔離 [1,2]。實現方法主要是在事務中增加兩個標識位(outConflict和inConflict)來標識該事務是否存在rw-dependency，同時增加新的鎖機制(Postgres中的predicate lock)來檢測讀寫依賴。

如上圖所示(圖來自[1])， 讀寫衝突分為兩種情況，一種是read-after-write，即T1寫入或者更新了記錄，T2在之後進行了讀取操作，SSI會在讀取的時候發現多版本中有對它不可見的新的版本，則會標記T1和T2之間的rw-dependency。 一種是write-after-read，即T2先進行了讀取操作，T1後進行更新，SSI利用SIREAD lock來檢測。以PostgreSQL為例，SSI會對訪問的tuple所在的relation，page和tuple進行加predicate lock。T1進行更新的時候，發現有predicate lock，則會去標記T1和T2之間的依賴關係。

分散式資料庫事務機制

主流分散式事務的設計與實現都是基於上述三種單機事務機制(2PL，OCC和MVCC)。

3.1 基於OCC的分散式事務

分散式OCC在執行階段將寫快取在本地，並追蹤讀訪問集合。在兩階段提交階段，需要對所有物件進行加鎖，然後進行驗證讀寫衝突，最後進行解鎖。在衝突比較多的情況下，事務處理的吞吐量會比較低。ROCOCO基於分散式OCC提出一種reorder的方法來減少分散式事務的衝突 [3]。MaaT採用動態時間戳技術來消除分散式OCC在兩階段提交階段的加鎖 [4]。

3.1.1 基於HTM和RDMA的優化

新的硬體特性(例如Intel的Restricted Transactional Memory和Remote Direct Memory Access)的出現提供了更加高效的分散式事務設計與實現選擇。DrTM採用HTM和RDMA特性基於OCC實現了非常高效的分散式事務 [5-7]。DrTM核心想法是利用HTM來實現高效的本地事務，利用RDMA的強一致性的one-sided read語義協同OCC的版本和鎖機制來實現高效的遠端事務。HTM通過追蹤CPU Cache的read-set和write-set來提供硬體事務語義(類似於OCC機制原理)，即可以把一段要原子執行的程式碼封裝在HTM介面中來執行。如果硬體事務T1訪問的資料被其它事務T2併發的修改，則T1事務會被abort。RDMA的強一致性one-sided read語義在修改遠端節點的CPU Cache Line的時候，會abort掉訪問過該Cache Line的HTM硬體事務。利用上述硬體的特性， DrTM採用軟體硬體協同設計的方法實現了分散式事務。例如DrTM將資料Cache Line對齊，並將鎖和版本號等後設資料放在第一個Cache Line頭部，這樣來利用RDMA的強一致性和HTM的Cache Track特性來實現高效的併發控制。

上圖 (來自[6])展示了 本地事務讀寫的虛擬碼邏輯。讀的操作如果在本地寫快取中，則直接返回寫值。如果不在，DrTM則會開啟HTM事務去讀取KV中的值，DrTM用HTM硬體事務來保護內部資料結構的併發訪問(B樹或Hash表)[7]。如果發現該記錄被寫事務鎖住了，則會abort本事務(讀取的記錄被併發修改)。本地寫則直接加入本地寫快取(修改由一個讀操作加一個寫操作組成)。

上圖(來自[6])展示了 事務利用RDMA遠端讀寫的邏輯。遠端讀的時候，一條記錄會有多條Cache Line組成，為了避免讀到不一致的資料，DrTM採用在每條Cache Line頭部加入序列號來檢測一致性。通過不斷重複度，一直讀到一致性的完整的資料。

上圖(來自[6])展示了 提交階段的邏輯。C.1進行加鎖，利用RDMA的CAS原子操作進行。如果發現已經被鎖住了，則abort(寫寫衝突)。C.2則是進行OCC裡面的驗證階段，驗證讀操作集合裡面的記錄是否被同時修改了(讀寫衝突)。C.3和C.4則是利用HTM來執行本地讀寫的邏輯。C.5則是更新遠端寫，同時更新記錄的序列號(用於其它事務檢測讀記錄是否被修改)，最後C.6解鎖所有記錄。

3.2 基於MVCC的分散式事務

設計與實現基於MVCC的分散式事務的關鍵在於 如何在多個節點讀取同一個一致性的全域性快照。一種方法是採用單機的快照機制，例如PGXL。分散式叢集中有一個節點(例如GTM)維護一個全域性範圍內正在執行的事務ID列表。每個事務開始的時候從GTM獲取一個當前正在執行的事務的快照，然後用這個快照去做tuple可見性判斷。該方法存在兩個問題： (1)開銷很大，加鎖生成快照的開銷和網路傳輸快照的開銷(快照大小等於當前併發事務數目); (2)很難保證正確性，一個事務在提交的時候，首先在每個節點進行提交，從本地活躍事務列表中移除，然後再從GTM中移除，這樣存在一個導致可見性判斷錯誤的時間視窗。

另外一種方式是採用時鐘的方式來保證，例如Google的Percolator [8]和Spanner [9]，以及MIT提出的Granola [14]。Percolator採用一個全域性時鐘生成器來生成遞增的時鐘，每個事務從這個timestamp server獲取事務的開始時間戳和提交時間戳，從而進行資料記錄可見性判斷。具體的，如果T1.start_timestamp > T2.commit_timestamp，則T2的修改對T1可見。這樣Percolator可以通過全域性時鐘來保證snapshot isolation。Percolator在底層的KV儲存中為每個tuple儲存多個timestamped版本，從而支援基於時鐘的可見性判斷。但這種全域性時鐘的方法仍然存在一個挑戰，即併發事務申請的時間戳到達每個節點的順序不一定一樣，可能會存在一個事務在不同節點看到不一致的檢視。

Percolator採用鎖的機制來解決這個問題，具體的，Percolator的事務會在預提交階段，在申請提交時間戳之前將它修改的物件加鎖。如果在這個物件在被鎖後，另外一個併發讀事務在訪問這個物件時，發現被加鎖，則會等待鎖結束再進行tuple可見性判斷，即比較時間戳。這樣可以保證，若T1.start > T2.commit，則T1可以在所有節點都看到T2.commit，從而一致性的看到T2的修改。

正確性證明：

物理世界事件發生的依賴關係是(TrueTime表示物理世界真實發生的精確時間):TrueTime(T1.lock)<TrueTime(T1.commit).

如果存在T2事務滿足LogicalTime(T2.start)>

LogicalTime(T1.commit)，則T1申請commit發生在T2收到start之前，即 TrueTime(T2.start)>TrueTime(T1.commit)。

TrueTime(T2.start) >TrueTime(T1.lock) (傳遞性)，則T2一定可以在所有節點都看到T1寫入的鎖記錄，從而等待T1.commit到來。證畢。

Spanner [9] 採 用物理真實時間(原子時鐘和GPS時鐘)來提供全球多資料中心的外部一致性(即分散式系統中很重要的特性Linearizability[11])。Spanner給所有事務都提供真實的commit timestamp，並且返回給客戶端。外部一致性的定義：如果T2.start > T1.commit，則T2.commit > T1.commit。即對外部客戶端來說，如果T2開始請求發生在T1的提交之後，Spanner保證T2的提交時間戳s2一定晚於T1的提交時間戳s1。

Spanner通過TrueTime API來提供帶有偏差bound的時鐘，即[time-delta1, time+delta2]。 為了避免時鐘偏差帶來的錯誤，Spanner的事務在提交階段會加入Wait來等待真實時間已經過了分配給它的時鐘，從而容忍機器之間的時鐘偏差(ms級別的skew)。

具體的時鐘演算法如下:

協調節點e1.commit(T1提交返回結果)和e2.start(開始T2事務)兩個事件，並且TrueTime(e1.commit) < TrueTime(e2.start)。

則協調節點給T1分配提交時間戳為s1，同時等待超過它的時鐘偏差再發起e1.commit，這樣保證s1 < TrueTime(e1.commit)

同時TrueTime(e2.start) <= s2，從而保證了s1 < s2。

Spanner 採用2PL機制來保證內部Serializable隔離性。為了加速只讀操作，Spanner為只讀事務 採用多版本免鎖機制。

MILANA [10]利用IEEE PTP精確時鐘同步協議，OCC和SDF(軟體定義的Flash)多版本來實現Serailizable隔離。MILNAN的一個創新是利用Flash SSD本來就存在的多版本機制來實現資料庫的多版本。MILANA事務也需要像Spanner一樣等待一個時鐘偏差來容忍不同機器之間的時鐘skew。

TBase分散式事務

我們設計的TBase分散式事務的 目標是提供snapshot isolation隔離(支援read committed和repeatable read兩種隔離級別)的同時， 保證TPCC吞吐量可以隨著節點規模增長而增長。

TBase採用全域性時鐘+MVCC多版本機制+2PC+SSI來達到上述目標。同時，TBase利用各個節點的SSI機制 [1-2] 來追蹤rw-dependency來實現全域性serializable隔離級別。2PC兩階段提交主要是用於 保證事務原子性的。

對於TBase分散式事務設計最大的挑戰是如何設計MVCC多版本回收機制。對於單機PostgreSQL的MVCC機制而言，事務xid分配是嚴格遞增的，並且如果xid1 < xid2，則xid2在執行的時候，xid1必定已經在執行了。而對於基於全域性時鐘的MVCC，分配的時間戳到達每個節點可能是亂序的。

如上圖所示，TBase的Coordinator 從GTS伺服器獲取遞增的GTS給事務分配開始時間戳和提交時間戳。但是並行事務在多個Data Node開啟的物理時間和分配給它們的邏輯時間戳不一定一致(受網路和作業系統排程等因素的影響)。如何解決回收事務和正在執行的事務之間的衝突具有很大的挑戰。

TBase分散式事務的主要的技術創新在於：

(1) 多核可擴充套件的遞增時鐘生成伺服器

(2) 低開銷的全域性時鐘一致性協議

(相比Google Percolator的寫鎖等待機制開銷更低)

(3) 新的基於全域性時鐘的MVCC多版本回收機制

(熱回收和冷回收)

在實現了上述機制後，TBase可以在標準的TPCC測試集上達到線性可擴充套件和超過300萬的TPMTotal的效能。資料庫叢集配置：30個資料節點和30個協調節點(TPCC客戶端執行節點)。測試的隔離級別為read-committed級別。

上圖表示的是TPCC吞吐量隨著節點規模增長而增長，60節點時包含30個資料節點和30個協調節點(TPCC客戶端執行節點)。

上圖表示在30協調節點和30資料節點時，TPCC吞吐量隨著TPCC的併發連線數上升而上升。

後續工作

TBase後續將研究利用硬體特性來進行加速，例如利用RDMA [13] 來加速網路訪問(包括GTS獲取)，設計新的資料中心有序硬體網路協議 [15, 16] 來更加高效的實現分散式事務等。

總結

事務ACID是資料庫的核心能力和特性，也是資料庫區別去其它儲存(例如KV)的一個重要區別。隨著儲存和處理資料量不斷增長(PB級)，資料庫向著 橫向擴充套件的方向發展(分散式資料庫)。在分散式場景下，如何提供分散式事務成為了一個非常重要和有挑戰的問題。 本文介紹了學術界和工業界在分散式事務設計與實現方面的例子以及他們的設計原理，然後闡述了我們的設計機制。TBase分散式事務在保證事務隔離(提供snapshot isolation，結合SSI可以提供serializable snapshot isolation)的同時提供了可擴充套件的OLTP效能，TPCC吞吐量可以隨著節點規模或者併發數增長而增長，在小規模叢集下可以超過300萬TPMTotal。

參考文獻

[1] Michael J. Cahill, Uwe Röhm, Alan David Fekete: Serializable isolation for snapshot databases. SIGMOD Conference 2008: 729-738

[2] Dan R. K. Ports, Kevin Grittner: Serializable Snapshot Isolation in PostgreSQL. PVLDB 5(12): 1850-1861 (2012)

[3] Shuai Mu, Yang Cui, Yang Zhang, Wyatt Lloyd, Jinyang Li: Extracting More Concurrency from Distributed Transactions. OSDI 2014

[4] Hatem A. Mahmoud, Vaibhav Arora, Faisal Nawab, Divyakant Agrawal, Amr El Abbadi: MaaT: Effective and scalable coordination of distributed transactions in the cloud. PVLDB 7(5): 329-340 (2014)

[5] Xingda Wei, Jiaxin Shi, Yanzhe Chen, Rong Chen, Haibo Chen: Fast in-memory transaction processing using RDMA and HTM. SOSP 2015: 87-104

[6] Yanzhe Chen, Xingda Wei, Jiaxin Shi, Rong Chen, Haibo Chen: Fast and general distributed transactions using RDMA and HTM. EuroSys 2016

[7] Zhaoguo Wang, Hao Qian, Jinyang Li, Haibo Chen: Using restricted transactional memory to build a scalable in-memory database. EuroSys 2014

[8] Daniel Peng, Frank Dabek: Large-scale Incremental Processing Using Distributed Transactions and Notifications. OSDI 2010: 251-264

[9] James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, J. J. Furman, Sanjay Ghemawat, Andrey Gubarev, Christopher Heiser, Peter Hochschild, Wilson C. Hsieh, Sebastian Kanthak, Eugene Kogan, Hongyi Li, Alexander Lloyd, Sergey Melnik, David Mwaura, David Nagle, Sean Quinlan, Rajesh Rao, Lindsay Rolig, Yasushi Saito, Michal Szymaniak, Christopher Taylor, Ruth Wang, Dale Woodford: Spanner: Google's Globally-Distributed Database. OSDI 2012: 251-264

[10] Pulkit A. Misra, Jeffrey S. Chase, Johannes Gehrke, Alvin R. Lebeck: Enabling Lightweight Transactions with Precision Time. ASPLOS 2017: 779-794

[11] Collin Lee, Seo Jin Park, Ankita Kejriwal, Satoshi Matsushita, John K. Ousterhout: Implementing linearizability at large scale and low latency. SOSP 2015

[12] Amy Tai, Michael Wei, Michael J. Freedman, Ittai Abraham, Dahlia Malkhi: Replex: A Scalable, Highly Available Multi-Index Data Store. USENIX Annual Technical Conference 2016: 337-350

[13] Wolf Rödiger, Tobias Mühlbauer, Alfons Kemper, Thomas Neumann:

High-Speed Query Processing over High-Speed Networks. PVLDB 9(4): 228-239 (2015)

[14] James A. Cowling, Barbara Liskov: Granola: Low-Overhead Distributed Transaction Coordination. USENIX Annual Technical Conference 2012: 223-235

[15] Jialin Li, Ellis Michael, Dan R. K. Ports: Eris: Coordination-Free Consistent Transactions Using In-Network Concurrency Control. SOSP 2017: 104-120

[16] Jialin Li, Ellis Michael, Naveen Kr. Sharma, Adriana Szekeres, Dan R. K. Ports: Just Say NO to Paxos Overhead: Replacing Consensus with Network Ordering. OSDI 2016: 467-483

推薦閱讀

騰訊雲SQL Server 效能逆天，252萬TPM國內無對手!

最高50萬QPS，騰訊雲新發布Redis 4.0標準版突破效能極限

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69940575/viewspace-2675215/，如需轉載，請註明出處，否則將追究法律責任。