乾貨 | 萬字長文帶你回顧OCC的前世此生

小螞蟻說：不久前螞蟻金服OceanBase微信帳號發佈的《悲觀仍是樂觀，這是一個問題》這篇文章帶着你們一塊兒概要描述了當前NewSQL的發展趨勢及使用到的相關併發控制技術（能夠點擊文章連接回顧）。今天咱們將爲你們重磅帶來該系列的續篇，以時間軸的方式帶你一塊兒全面回顧OCC在學術界及工業界的發展歷程。

OCC（Optimstic Concurrency Control）,從廣義上理解，OCC表示一種樂觀併發控制的思想，只在事務提交時對事務是否符合串行化進行驗證；而悲觀併發控制（Pessimistic Concurrency Control）會對事務執行過程當中的每一個操做進行串行化驗證。在這一思想的指導下，應用層的樂觀鎖也屬於OCC；從狹義上理解，OCC特指一個具體的不依賴加鎖的併發控制技術，與2PL/TO/MVCC等處於同一個概念層次，屬於數據庫內核層。本文如下提到的OCC指代的是狹義的概念。

本文是該系列文章的第二篇，下一篇將致力於爲你解讀FoundationDB如何實現OCC。敬請關注螞蟻金服OceanBase微信帳號瞭解更多！

前言

上一篇 提到了蘋果新近開源的FoundationDB基於NoSQL+ACID架構實現了一個支持事務語義的NoSQL數據庫，並由此簡單回顧了一下開源社區從NoSQL到NewSQL運動的轉變，同時強調了Google在這一變革中起到的決定性做用，最後列出了當前幾種流行的NewSQL生產級分佈式數據庫所使用的併發控制技術及支持的隔離級別，能夠明顯看出FoundationDB在併發控制技術上的獨樹一幟。

本篇爲該系列文章的續篇，以時間軸的方式對不一樣時期的有表明性的論文（從理論研究、原型系統、生產系統三個維度分類）進行了梳理，帶你簡要回顧一下OCC在學術界及工業界的發展歷程。

這裏須要先對 OCC（Optimistic Concurrency Control） 指代的概念作一個說明，從廣義上理解，OCC表示一種樂觀併發控制的思想，只在事務提交時對事務是否符合串行化進行驗證；而悲觀併發控制（Pessimistic Concurrency Control）會對事務執行過程當中的每一個操做進行串行化驗證。

在這一思想的指導下，應用層的樂觀鎖也屬於OCC；從狹義上理解，OCC特指一個具體的不依賴加鎖的併發控制技術，與2PL/TO/MVCC等處於同一個概念層次，屬於數據庫內核層。本文如下提到的OCC指代的是狹義的概念。

本文重點在於沿着OCC發展的時間線的梳理，因爲相關論文較多，做者沒法深刻探究每篇論文的詳細內容，僅描述了論文中的大體思想，可能也有不全面或錯誤的地方，感興趣的同窗能夠研讀論文原著。

前世

理論研究——集中式OCC

On Optimistic Methods for Concurrency Control 1981

OCC技術最先由CMU大學的H.T. KUNG教授提出，當時數據庫併發控制研究的熱點是2PL，做者直接列舉了基於鎖的併發控制協議的五宗罪：

1. 加鎖協議開銷大，對於不會改變數據庫約束完整性的只讀事務也須要加讀鎖保護以防止別人修改；對於可能形成死鎖的加鎖協議還須要額外增長死鎖檢測開銷

2. 爲了不死鎖，須要定製各類複雜的加鎖協議

3. 在持有鎖的狀況下可能會等待I/O操做，會大幅下降系統總體的併發吞吐量

4. 加鎖事務回滾時必須持有鎖，直到事務回滾結束，下降了系統總體的併發吞吐量

5. 只有在最壞狀況下才須要加鎖；不少真實的應用場景每每是高併發低競爭的

做者據此提出了一種新的樂觀併發控制方法用於解決上述問題（所謂的樂觀是針對併發事務衝突機率極低的工做負載場景），該方法將一個事務的生命週期劃分爲三個階段：

• 讀取階段
• 全部更新操做緩衝在事務本地內存空間中，維護事務的寫集
• 全部讀取操做先訪問事務本地內存空間，若不存在則從數據庫中讀取並可選地緩存在事務私有內存空間中，維護事務的讀集
• 驗證階段

根據某種可串行化標準檢查待提交事務是否知足可串行化調度

• 寫入階段（只讀事務不須要）

將事務私有內存中的更新數據寫入數據庫使其全局可見

假設系統中每一個事務可以被賦予全局惟一的事務號，則有事務號Ti和Tj，且Ti<Tj，能夠將系統內是否存在一個與事務號順序等價的併發事務調度序列做爲可串行化標準，則檢查事務Tj是否符合可串行化（即Ti在Tj以前完成），需知足以下三種條件之一：

一、Ti在Tj開始讀取階段前完成寫入階段，即Ti在Tj以前提交

二、Ti的寫集與Tj的讀集不相交，且Ti在Tj開始寫入階段前完成寫入階段

三、Ti的寫集與Tj的讀集和寫集都不相交，且Ti在Tj完成讀取階段前完成讀取階段

做者提出了兩種知足上述條件的驗證階段實現方案：

一、串行方案（事務併發知足條件1或2）

事務開始

獲取當前已提交的事務號

事務結束

① 進入臨界區

② 獲取當前已提交的事務號

③ 驗證事務開始和結束期間提交的事務的寫集與待驗證事務的讀集是否相交

④ 相交，則發現衝突，退出臨界區並停止待驗證事務

⑤ 不相交，則驗證成功，執行寫入階段（若是是隻讀事務無需執行）並遞增提交事務號

⑥ 退出臨界區

二、並行方案（事務併發知足條件1或2或3）

事務開始

獲取當前已提交的事務號

事務結束

① 在臨界區內獲取當前已提交的事務號/獲取當前活躍事務列表/將自身加入活躍事務列表

② 驗證事務開始和結束期間提交的事務的寫集與待驗證事務的讀集是否相交

③ 驗證活躍事務（這些活躍事務均已完成讀取階段，讀集和寫集不會再發生變化，可理解爲進入驗證的事務列表）的寫集與待驗證事務的讀集和寫集是否相交

④ 相交，則發現衝突，在臨界區內將本事務從活躍事務中去除並停止待驗證事務

⑤ 不相交，則驗證成功，執行寫入階段（若是是隻讀事務無需執行）

⑥ 在臨界區內遞增提交事務號並將本事務從活躍事務中去除

在系統實現中，還須要考慮兩種特殊狀況的解決方案：

一、長事務

根據上述規則，須要檢查長事務開始時未提交的事務的寫集。因爲數據庫系統只能維護有限的事務寫集，做者建議只維護最近事務的寫集，若是驗證時沒法找到事務號對應的寫集，則停止待驗證事務並從新執行。

二、餓死現象

驗證失敗時事務須要停止並從新執行，存在一種極端狀況使得事務持續地停止並從新執行，做者建議記錄事務的失敗驗證次數，若超過必定閾值，則在臨界區內從新執行事務，完全排除其它併發事務的干擾。

顯然，上述方案都是針對單數據版本的集中化數據庫系統，在分佈式數據庫系統中的OCC算法還有待後人擴展。

理論研究——分佈式OCC

Optimistic Methods for Concurrency Control in Distributed Database Systems 1981

Problems of Optimistic Concurrency Control in Distributed Database Systems 1982

這兩篇論文提出了將原集中化數據庫系統中的OCC應用到分佈式數據庫系統中的解決方案，第一篇論文的內容始終沒法找到，本文猜想其基本思想爲：

• 讀取階段與集中化數據庫系統中的方案相似
• 全局事務的驗證階段能夠分解爲每一個結點上的本地子事務的驗證階段，若是全部的子事務驗證經過，則全局事務驗證經過
• 驗證和寫入階段與分佈式系統中的2PC結合，驗證屬於prepare階段，寫入屬於commit階段

做者緊接着在第二篇論文中指出了OCC在分佈式系統中面臨的兩個關鍵問題及可能的解決方案：

• 問題一

全局事務的驗證階段和寫入階段沒法保證在臨界區內順序執行

• 可能的解決方案
• 強制前一個事務完成寫入階段後才能開始下一個事務的驗證階段
• 採用論文[1]的並行版本
• 問題二

全局事務中各本地子事務的驗證階段採用的可串行化標準可能不一致

• 可能的解決方案
• 使用全局事務號保證各結點在驗證階段使用相同的可串行化標準

理論研究——BOCC和FOCC

Observations on optimistic concurrency control schemes 1984

對論文[1]中OCC的串行版本進行了擴展，由此歸類出兩種OCC驗證方案：

• BOCC （論文[1]方案）

檢查待驗證事務的讀集是否與事務讀取階段完成的事務的寫集有交集

• FOCC

檢查待驗證事務的寫集是否與當前活躍事務的讀集有交集

BOCC有以下缺點：

• 只讀事務也須要驗證階段
• 只能停止當前驗證事務
• 待驗證事務的讀集可能很大
• 對於長事務可能須要保留大量期間已提交事務的寫集

反之，FOCC有以下優勢：

• 只讀事務無需驗證階段
• 只需與當前有限的活躍事務進行驗證且驗證事務的寫集一般狀況下較小
• 靈活的衝突策略，可選擇延遲或停止驗證事務，也可選擇停止衝突事務

同時，做者從實現角度列舉了OCC的一些通用問題：

• 高事務停止率
• 依賴同步機制避免事務餓死
• 讀集/寫集的維護浪費內存空間
• 讀取階段看到的數據庫視圖不一致
• 幻讀問題很差解決
• 行粒度OCC讀取階段數據可能不一致
• 行粒度OCC寫入階段開銷可能很大
• 行粒度OCC查詢階段流程複雜
• 頁面粒度OCC會浪費空間並增大沖突停止機率

這篇論文整體看來對OCC的評價是負面的，但羅列出的通用問題也爲後續的OCC研究者指出了改進的方向。

原型系統——MVCC+OCC+2PC

Distributed transaction management in jasmin VLDB 1984

這篇論文給出了OCC在分佈式系統實現層面的解決方案，系統採用多版本存儲，數據對象的粒度爲一個頁面，事務流程簡要描述以下：

• 讀取階段

選取全局讀時間戳，保證讀取階段可以看到一致的數據庫視圖。對於只讀事務，在讀取階段結束後就能夠提交。

事務寫頁面時會在系統內部建立影子頁面。

• 驗證階段/寫入階段

使用兩階段提交完成驗證和寫入階段：

一、獲取一個全局的事務時間戳

二、由協調者消息通知相關各結點啓動驗證階段

三、各結點統一使用該全局時間戳，基於論文[1]中提到的並行驗證版本進行驗證

四、協調者根據收到的全部的驗證反饋決定發送提交仍是停止消息

該論文從原型實現驗證了OCC落地的可行性，並首次使用全局時間戳解決OCC讀取階段數據庫視圖不一致及全局事務中子事務串行化驗證標準不一致的問題。

理論研究——動態調整提交時間戳減小事務停止率

Certification by intervals of timestamps in distributeddatabase systems 1984

論文認爲[1]中的OCC是將事務進入驗證階段的時間做爲事務提交時間戳並據此調度事務的可串行化，這會致使一些非必要的事務停止，提出一種在驗證階段基於訪問數據的時間戳版本動態調整事務提交時間戳的方法，其基本思想以下：

基本數據結構：

• 在事務訪問的每一個結點上須要維護該事務的提交時間戳區間
• 每一個數據對象維護一個最大讀時間戳和最大寫時間戳，這些時間戳均爲已提交事務的提交時間戳
• 每一個結點維護活躍事務表及其讀集、寫集
• 每一個數據對象維護讀/寫過該對象的活躍事務

基本流程：

事務初始提交時間戳區間設置爲0到正無窮

一、讀取階段

① 事務執行過程當中訪問任意結點上的數據時都須要傳遞客戶端上的事務提交時間戳區間信息

② 進入臨界區

③ 結點將客戶端提交時間戳區間信息與本地維護的提交時間戳區間求交集獲得最新的提交時間戳區間信息

④ 根據讀寫類型區別操做

• 若是是讀操做，將事務提交時間戳區間的下限設置爲數據對象的最大寫時間戳+1；將事務加入數據對象的讀事務列表中；將數據對象加入結點維護的事務讀集中
• 若是是寫操做，將事務提交時間戳區間的下限設置爲數據對象的最大寫時間戳與最大讀時間戳之間的最大值+1；將事務加入數據對象的寫事務列表中；將數據對象加入結點維護的事務寫集中

⑤ 更新本地事務提交時間戳區間信息

⑥ 向客戶端回傳最新的事務提交時間戳區間信息及讀取的值

⑦ 退出臨界區

⑧ 客戶端將回傳信息與當前信息做交集獲得最新的時間戳區間（經過這種方式使得結點可以感知到事務在其它結點上的依賴信息，便於早發現不符合串行化調度的事務）

二、 驗證和寫入階段 （因爲其它事務的讀寫操做與當前事務的驗證階段都會修改事務的時間戳區間，因此結點上的讀寫操做與驗證時的調整操做須要互斥）

① 客戶端向各參與結點發送驗證/提交消息（消息中包含驗證事務的最新提交時間戳區間）

② 提議階段

• 參與結點將最新提交時間戳與本地合併後廣播給集羣中的全部其它結點
• 同步等待其它結點，最終獲得一個全部結點一致的待驗證事務提交時間戳區間

③ 時間戳選擇階段

• 若是該時間戳區間無效（空集），則停止事務
• 不然，在有效區間內選擇一個具體的提交時間戳（全部結點上的時間戳選擇策略要一致，該時間戳影響讀衝突事務的上限/寫衝突事務的下限，若是選擇提交時間戳區間下限，意味着可以避免更多的寫衝突事務的停止，增大讀衝突事務的停止；反之，則效果相反）

④ 調整及寫入階段

• 對於驗證事務讀集中的每一個數據對象，調整該對象上的全部活躍寫事務的提交時間戳下限爲驗證事務提交時間戳+1；若是驗證事務提交時間戳大於數據對象上的最大讀提交時間戳，則修改成驗證事務的提交時間戳
• 對於驗證事務寫集中的每一個數據對象，調整該對象上的全部活躍讀事務的提交時間戳上限爲驗證事務提交時間戳-1；調整該對象上的全部活躍寫事務的提交時間戳下限爲驗證事務提交時間戳+1；調整該對象的最大寫提交時間戳爲驗證事務提交時間戳並設置爲更新的數據
• 清除結點上與驗證事務相關的信息，返回客戶端事務已提交

做者爲了發現串行化衝突，須要結點在驗證階段開啓時將本結點的事務時間戳區間信息廣播到全部結點，等到所有結點回復後纔開始對事務進行串行化檢查，在分佈式系統中人爲設置了同步點，對擴展性會有必定的影響。

其它關於OCC的研究主要集中在與傳統併發控制技術的性能對比[5]，如何減小沒必要要的事務停止率[9]，同時支持2PL與OCC[4]，如何防止事務餓死[10]及OCC在實時數據庫系統中的應用[11]，能夠看出，這一時期OCC基本處於學術研究及原型驗證階段，當時的數據庫工業界，如Oracle、DB2，仍是使用了主流的併發控制技術，如2PL、MVCC。

此生

進入21世紀後，數據庫運行的硬件基礎設施在向兩個方向發展：

• 內存數據庫

隨着硬件技術的發展，如論文[12][19]中所述，多核（幾10、幾百）、大內存（T級別）的單節點配置已在市場上出現，意味着大多數OLTP場景下的數據處理能夠徹底運行在內存中，SAP HANA、MemSQL、TimesTen、SolidDB、Hekaton等內存數據庫也應運而生。

• 分佈式NewSQL數據庫

隨着互聯網應用的興起，標榜着高可靠、高可用、高可擴展的NoSQL運動席捲而來，運行環境也由大型機過渡到分佈式集羣、多數據中心、多可用區等；NoSQL系統雖然實現了承諾的目標，但其不支持SQL語言、缺少強一致性的短板一直備受開發人員的抱怨，因而NewSQL系統又進入了人們的視野，其主打口號是既具備NoSQL的全部優勢而且還支持SQL語言及ACID事務，如F一、Spanner、CockroachDB、TiDB、OceanBase等。

與傳統併發控制方法相比，OCC的優勢是在高資源競爭、低數據競爭場景下，可以減小事務運行同步開銷，避免死鎖，支持更高的事務吞吐率；缺點是在高數據衝突場景下有較高的事務停止率，浪費計算資源（2PL在此場景下事務停止率也很高，但可以提早停止，不用等到事務提交時）。

上述兩種場景，一個關注單機事務吞吐量；另外一個關注分佈式事務吞吐量，其性能優化目標能夠統一描述爲在硬件資源充足的狀況下如何提升事務吞吐量。節約資源已再也不是重點，減小系統同步，提升資源利用率纔是核心問題。尤爲是在分佈式計算環境下，網絡交互的延遲或異常容易致使2PL協議可能長時間持有鎖從而致使系統總體事務吞吐率下降或死鎖。OCC的價值在新的數據庫基礎設施環境上又得到了學術界與工業界的重視。

生產系統——在驗證階段使用Paxos提交協議發現衝突

Megastore: Providing Scalable, Highly Available Storage for Interactive Services CIDR 2011

Megastore是少有的在內核層實現OCC的生產級分佈式數據庫系統，在Entity Group的數據分區級別使用MVOCC實現了串行化隔離級別的事務，同一分區一次只能執行一個事務，分佈多副本間能夠併發執行事務。一個OCC事務三個階段的實現大體描述以下：

一、讀取階段

① 在任意副本都可發起強一致讀；數據更新緩存在應用的事務私有內存

② 從多數派副本中獲取最新事務提交時間戳及事務日誌的位置（能夠經過查詢本地coordinator中副本的數據狀態作優化）

③ 選擇一個合適的副本（綜合考慮本地性、響應時間、事務提交時間等），使用Paxos協議同步事務日誌並將其應用到本地Bigtable中

④ 若選擇了本地副本，則異步更新coordinator中副本數據狀態爲有效

⑤ 根據獲取的事務提交時間戳從本地Bigtable中讀取數據

二、驗證階段

① 從強一致讀獲得的事務日誌中獲取下一次寫入事務日誌的位置

② 選取一個比最新事務提交時間戳更大的值做爲本次事務提交時間戳

③ 將事務私有內存中的更新打包到一個事務日誌中

④ 發起一次完整的兩階段Paxos協議實例（能夠優化爲一階段Paxos協議），一個事務日誌位置只能由一個事務提交成功。若是成功，則將未成功接受當前事務日誌的副本所對應的coordinator中的數據狀態設置爲失效，通知應用事務已提交；若是失敗（prepare階段發現提交的內容與達成一致的內容不匹配），則終止事務並從新執行

三、寫入階段（異步執行）

將更新數據異步寫入Bigtable，清理應用事務私有內存數據

由上述流程能夠看出，Megastore將事務侷限在一個EG且只能串行化執行，併發衝突的控制粒度在事務級別，致使事務吞吐率很是低。雖然論文[15]中提出了一種提升Megastore事務提交吞吐量的可能方案，但Google內部最終仍是放棄了Megastore，轉而使用了Spanner（使用MV2PL併發控制技術），由於Spanner經過2PL+2PC實現了跨分區的事務。

生產系統——MVCC+OCC在內存數據庫中的落地

High-Performance Concurrency Control Mechanisms for Main-Memory Databases VLDB 2012

真正把OCC在生產系統中落地的是內存數據庫Hekaton，論文使用全內存的無鎖哈希表存儲多版本數據，數據的訪問所有經過索引查找實現，一個OCC事務的生命週期實現以下：

1. 正常處理階段（讀取階段）

① 獲取事務開始時的當前時間做爲讀時間戳並賦予一個惟一的事務號，事務狀態設置爲active

② 在事務處理的過程當中維護讀集（指向讀版本的指針）、寫集（指向寫版本的指針）、掃描集（從新執行掃描時須要的信息，如掃描條件）

③ 更新數據時（總在最新的版本上更新），版本可更新的判斷：

a. 更新數據的end域無效或事務號所屬事務已經停止

• 將原始版本的end域原子更新爲當前事務號，防止其它事務的併發修改
• 連接新的數據版本並設置begin域爲當前事務號
• 可能會出現更新begin域的事務處於preparing狀態的數據版本，採起投機更新策略並記錄提交依賴

b. 更新數據的end域事務號所屬事務處於active或preparing狀態

寫寫衝突，更新事務須要停止

④ 讀取數據時，版本可見性的判斷：

a. 讀取數據的begin/end域都是有效的時間戳

若是讀時間戳在begin/end之間，則可見；不然不可見

b. 讀取數據的begin域是事務號

• 若是事務號所屬的事務狀態爲active，僅對事務號所屬事務可見
• 若是事務號所屬的事務狀態爲preparing，讀時間戳若是比事務提交時間戳大，則採起投機讀策略並記錄提交依賴（引入了級聯停止問題）
• 若是事務號所屬的事務狀態爲aborted，直接忽略
• 若是事務號所屬的事務狀態爲commited，讀時間戳若是比事務提交時間戳大，正常讀取

c. 讀取數據的end域是事務號

• 若是事務號所屬的事務狀態爲active，僅對事務號所屬事務不可見
• 若是事務號所屬的事務狀態爲preparing，讀時間戳若是比事務提交時間戳大，則採起投機忽略策略並記錄提交依賴（引入了級聯停止問題）；讀時間戳若是比事務提交時間戳小，則可見
• 若是事務號所屬的事務狀態爲aborted，可見
• 若是事務號所屬的事務狀態爲commited，讀時間戳若是比事務提交時間戳小，則可見

二、準備階段（驗證階段）

① 獲取當前時間戳做爲提交時間戳，事務狀態設置爲preparing

② 讀集有效性驗證，檢查讀集中的版本是否依然可見；從新執行掃描集檢查是否存在幻讀

③ 等待提交依賴所有完成或當前事務是否已被其它事務設置爲停止

④ 同步寫redo日誌

⑤ 將事務狀態設置爲commited

三、後處理階段（寫入階段）

① 若是提交，將新數據的begin域和舊數據的end域設置爲提交時間戳

② 若是停止，將新數據的begin域設置爲無效，嘗試將舊數據的end域設置爲無效（若是已被其它事務更新則忽略）

③ 處理提交依賴，若是提交，則減小依賴該事務的其它事務的提交依賴計數；若是停止，則通知依賴該事務的其它事務停止

④ 清理事務表

生產系統——應用層OCC在分佈式環境的價值

F1: A Distributed SQL Database That Scales VLDB 2013

F1是Google內部研發的分佈式關係數據庫，存儲層基於Spanner，自建SQL層，用於Google最重要的廣告業務。F1在Spanner之上基於行級的修改時間戳列實現了樂觀事務並將其設置爲默認配置，論文提到使用樂觀事務有以下優缺點：

• 優勢
• 容忍客戶端的不正確行爲（如無心義的長事務或未正常結束的事務）
• 長事務/交互式事務友好（沒有鎖超時致使停止的問題/用戶查詢期間不持有鎖）
• 服務端重試友好，對用戶透明
• 事務更新狀態保存在客戶端，利於容災及負載均衡
• 易於實現投機寫（檢查讀數據的版本變動發現衝突）
• 缺點
• 幻讀問題須要藉助其它手段避免
• 高數據競爭場景下的低事務吞吐率

其中關於OCC優勢的描述來自生產級分佈式環境運維的最佳實踐經驗，雖然只是應用層的簡單實現，但也從另外一方面驗證了OCC在現代分佈式數據庫環境中的技術價值。

原型系統——動態調整提交時間戳減小事務停止率

MaaT: Effective and scalable coordination of distributedtransactions in the cloud VLDB 2014

這篇論文能夠稱爲是爲OCC搖旗吶喊的戰鬥檄文。論文首先提出了事務級雲存儲系統的概念，有表明性的系統如工業界的Spanner、學術界的Calvin、開源界的MySQL Cluster。與傳統事務級雲數據庫的區別在於更加透明的數據分區，包括自動化的分區拆分、合併、遷移、負載均衡，這使得高效的跨結點分佈式事務成爲一個必選功能。

當前實現跨結點分佈式事務的併發控制技術要麼是2PL（Spanner、MySQL Cluster），要麼是靜態鎖（Calvin，對事務操做進行靜態分析後提早加鎖），而OCC僅在應用層或Megastore中有所應用。OCC沒有被廣泛使用的緣由有以下兩點：

• 就適用場景來看，OCC適合於交互式或系統內部組件同步延時較大的場景，而在數據庫系統內，磁盤、網絡延時一般以毫秒計，OCC致使事務停止浪費計算資源的開銷劣勢遠大於減小同步開銷的優點
• 在分佈式數據庫實現中，OCC在寫入階段的原子提交協議依然依賴於2PC中的鎖機制，沒有完全消除鎖機制在雲環境中可能會形成的死鎖、下降事務吞吐量、系統資源利用率降低等問題

可是在雲環境下，一個理想的雲數據庫應該知足以下要求：

• 在長事務、跨結點事務、高數據熱點、高通訊延時等場景下依然可以支持高事務吞吐率
• 高效的CPU利用率
• 高擴展性，減小系統內的同步點
• 高併發場景下沒有系統性能抖動
• 系統無死鎖或永久阻塞點

OCC在這種場景下是有技術優點的，所以，論文致力於實現一個消除2PC中的鎖機制且大幅下降事務誤停止率的分佈式數據庫系統MaaT。MaaT的理論基礎基於論文[8]並在系統實現上進行了優化，其基本思想以下：

基本數據結構：

• 在事務訪問的每一個結點上須要維護內存事務表，記錄事務的提交時間戳區間及當前狀態（runing/validated/committed/aborted）
• 每一個數據對象維護一個最大讀時間戳和最大寫時間戳，這些時間戳均爲已提交事務的提交時間戳
• 每一個數據對象維護讀/寫過該對象的活躍事務號

基本流程：

一、讀取階段

① 在事務請求結點上分配一個全局惟一事務號，並在內存事務表中初始化事務信息（提交時間戳區間設置爲0到正無窮，狀態設置爲running）

② 事務執行過程當中第一次訪問任意遠程結點上的數據時都須要在結點本地的內存事務表中創建事務相關初始信息

③ 根據讀寫類型區別操做

• 讀操做
• 將事務號加入讀對象的未提交讀事務號列表
• 返回讀對象數據、讀對象上當前加寫鎖的活躍事務號及讀對象的最大寫時間戳（事務提交時需保證提交時間戳小於全部該對象上寫事務的時間戳並大於最大寫時間戳）
• 客戶端將返回數據緩存在事務私有內存中
• 寫操做
• 將更新數據寫入客戶端的事務私有內存中

二、驗證階段

① 客戶端發送預寫/驗證消息到全部相關數據服務器（讀寫涉及到的服務器），消息中包括與服務器相關的讀集、寫集及在讀取階段從服務器獲取的信息（全部在讀對象上加寫鎖的活躍事務號及最大寫時間戳）

② 預寫（處理服務器上的寫操做）

1. 收到消息的服務器將事務號加入寫對象的未提交寫事務列表
2. 寫事務日誌
3. 獲取在寫對象上加讀鎖的活躍事務號及最大讀提交時間戳（事務提交時需保證提交時間戳大於全部該對象上讀事務的時間戳並大於最大讀時間戳）
4. 獲取在寫對象上加寫鎖的活躍事務號

③ 驗證（保證事務的串行化順序按提交時間戳排序，經過調整事務提交時間戳區間的上下限實現，調整的原則爲儘可能減小事務停止率）

1. 對於讀集中的對象，須要保證驗證事務能在讀對象的最大寫時間戳以後提交
2. 對於讀對象上的加寫鎖事務，須要保證在驗證事務以後提交
3. 對於寫集中的對象，須要保證驗證事務在寫對象的最大讀時間戳以後提交
4. 對於寫對象上的加讀鎖事務，須要保證在驗證事務以前提交
5. 對於寫對象上的加寫鎖事務，須要保證在驗證事務以後提交

④ 驗證結束後，若是驗證事務的提交時間戳區間有效（下限小於等於上限），則將事務狀態改成validated；不然，將事務狀態改成aborted

⑤ 各結點通知客戶端事務狀態及調整後的提交時間戳區間

三、寫入階段

① 若是有結點返回aborted，則事務最終狀態爲aborted

② 若是全部結點均返回committed，則計算全部提交時間戳區間的交集，區間無效，則事務最終狀態爲aborted；不然事務最終狀態爲committed，此時客戶端須要從有效區間中選取任意的時間戳做爲該事務的提交時間戳

③ 客戶端向相關數據結點發送事務提交或停止消息，提交消息中包含更新數據及肯定的提交時間戳

④ 對於abort消息，數據結點將本地事務表中的事務狀態改成aborted，刪除該事務在數據對象上加過的鎖並記錄事務停止日誌

⑤ 對於committed消息，數據結點將本地事務表中的事務狀態改成committed，提交時間戳區間設置爲客戶端肯定的時間戳，刪除該事務在數據對象上加過的鎖並記錄事務提交日誌

⑥ 對於讀集中的數據對象，若是事務提交時間戳大於讀對象的最大讀時間戳，則將讀對象的最大讀時間戳設置爲事務提交時間戳

⑦ 對於寫集中的數據對象，若是事務提交時間戳大於寫對象的最大寫時間戳，則將寫對象的最大寫時間戳設置爲事務提交時間戳並修改寫對象的內容

論文提出的OCC實現方案被2017年的VLDB論文[21]做爲測試OCC性能的參考實現，間接證實這裏提出的OCC算法已經獲得了學術界的承認，雖然論文[21]中對新OCC算法的性能與其它併發控制算法的比較仍然沒有正面評價，但性能瓶頸已經轉移到網絡傳輸及CPU計算消耗，事務停止率及同步開銷已成爲性能瓶頸的次要因素，OCC的擴展性獲得了提升。

原型系統——分佈式驗證

Centiman: Elastic, High Performance Optimistic Concurrency Control by Watermarking 2015

Centiman是一個在雲環境基於NoSQL存儲層+事務處理層（OCC）實現的具有串行化事務隔離級別的KV系統，由KV存儲、事務處理子系統（包括處理結點和驗證結點）、全局總控結點及客戶端組成。

一個事務的完整生命週期分爲以下階段：

• 讀取階段

1. 處理結點維護一個本地的已應用事務提交時間戳（watermark，此時間戳以前的數據更新已寫入kv存儲）及其它節點已應用事務提交時間戳的緩存（緩存按期異步更新）

2. 每次讀操做讀取最新版本的kv，處理結點會計算最新的watermark時間（取全局最小），將key、version、watermark記入讀集；寫入操做需將kv緩存處處理結點的事務私有內存空間並將key記入寫集

• 驗證階段

1. 只讀和讀寫事務都須要走驗證流程（優化：處理結點若發現待驗證事務的全部讀時間戳都小於事務第一次讀時的watermark，則直接向客戶端返回提交）

2. 處理結點給待驗證事務賦值一個全局單調遞增的提交時間戳

3. 將執行階段記錄的讀集、寫集按照key的某種分片規則分別發送到對應的驗證結點，同時將事務私有內存中的數據異步寫日誌

4. 每一個驗證節點維護一個滑動時間窗口，小於滑動時間窗口到來的驗證請求則直接返回驗證失敗；落在滑動窗口內的驗證請求按照事務提交時間戳順序進行處理並持續推動滑動窗口

5. 採用BOCC算法進行驗證，對於事務在某個分片驗證節點讀集中的每一個key，在驗證結點緩存的事務寫集中查找全部在讀key時間戳和待驗證事務提交時間戳之間提交的事務並驗證讀key是否與已提交事務的寫集衝突 （優化：若是讀key時間戳小於記錄的watermark時間戳，則衝突檢查區間能夠縮小爲在watermark時間戳和待驗證事務提交時間戳之間）

6. 若衝突，則停止事務；不然，將待提交事務的寫集緩存在驗證節點用於後續新事務的驗證並提交事務

7. 若是全部相關驗證結點都贊成提交事務，則發起驗證的處理結點寫提交日誌並通知客戶端，轉入寫入階段；不然直接通知客戶端事務已停止（可能存在有些驗證結點認爲應該提交，有些驗證結點認爲應該終止的狀態，雖然事務總體是終止狀態，但部分驗證結點會存在衝突誤判，論文中也是依賴watermark機制儘可能減小誤判）

• 寫入階段

1. 處理結點將事務本地內存中的更新內容寫入kv存儲（寫入過程不要求保證原子性，容許其它事務讀到部分寫入的新值；經過kv存儲的MVCC機制保證提交時間戳靠後的事務寫入的數據不會被提交時間戳靠前的事務寫入的數據覆蓋）

2. 待所有寫入成功後，更新本地watermark並異步記錄事務已完成日誌

這個系統的實現架構是具備必定表明性的，全部不支持ACID事務的NoSQL系統均可以參照此原型架構實現串行化事務隔離級別，後續咱們要研究的FoundationDB架構也與此相似，固然生產環境的數據庫還會考慮更具體的問題，好比幻讀的處理、性能優化等。

至此，本文列舉了OCC在這一時期在學術及工業界的主要結果，能夠看出主要是性能優化，擴展性提升及生產級系統的實踐。這裏也忽略了一些有表明性的OCC系統，好比Percolator[13]、Silo[17]，由於這些系統在併發控制實現中使用了鎖機制並存在寫讀阻塞的狀況，雖然能夠下降事務停止率，但卻違背了OCC讀寫不阻塞、沒有死鎖的理念。

相比於前世理論研究的玩具，應用場景的缺少，此生在內存及分佈式數據庫場景的落地，理論與工業界不斷地性能優化等方面屢有建樹，其技術帶來的實際使用價值正愈來愈多地獲得系統架構設計人員的承認，尤爲是在跨分區、跨數據中心、跨地域分佈式事務[22]，實現串行化隔離級別等現今分佈式數據庫還沒有深刻觸碰的領域有着巨大的挖掘潛力。

結語

本文按照時間線簡要回顧了OCC從誕生、理論研究、原型系統驗證到生產系統落地的發展脈絡，從中能夠看出OCC技術從1980年代初發展至今將近40年的時間了，一路走來磕磕絆絆，從不適用於傳統單機數據庫，到在內存數據庫中落地生根；從不適用於分佈式數據庫，到完美實如今NoSQL分佈式數據庫上支持ACID事務，甚至在跨分區事務、跨地域分佈式系統的研究中也體現出了巨大的優點，有理由相信OCC技術的樂觀、儘可能減小事務同步開銷的理念在將來的雲環境中會有更多的運用。

在梳理OCC發展歷程的過程當中，筆者也逐漸總結出從技術角度應該如何分析實現了OCC的分佈式數據庫系統（仍有待完善）：

• 讀取階段
• 是否保證讀一致性
• 使用事務私有內存仍是共享數據內存
• 私有內存在客戶端仍是服務端
• 私有內存在服務端是單結點仍是多結點
• 私有內存是否存儲讀入的數據
• 如何儘早發現衝突
• 驗證階段
• 事務提交時間戳如何分配
• 驗證算法是BOCC仍是FOCC模式
• 驗證和寫入階段是否須要原子完成
• 如何解決幻讀問題
• 如何下降事務停止率
• 如何避免事務餓死
• 如何下降長事務停止率
• 如何優化只讀事務
• 寫入階段
• 是否要求原子性
• 使用了什麼樣的原子提交協議，2PC、Paxos仍是不須要

身爲一名程序員，筆者恪守Linus Torvalds大神說過的話：

talk is cheap, show me the code

把OCC在生產系統中落地的只有Microsoft的內存數據庫Hekaton和Google的分佈式KV數據庫Megastore。雖然論文[14]、[15]、[16]對Megastore、Hekaton及相關的OCC進行了原理性的概要描述，但仍是沒法從代碼實現細節上對OCC落地時可能遇到的實際問題進行解惑。好在蘋果今年4月份開源了FoundationDB（又一個使OCC落地的新軍），讓碼農有機會從代碼實現層面上更詳細地瞭解如何將OCC落地。

（本文僅表明做者我的觀點，不表明OceanBase立場）

下期預告

本文是該系列文章的第二篇， 下一篇將致力於爲你解讀FoundationDB如何實現OCC。敬請期待！

參考文獻

1. On Optimistic Methods for Concurrency Control 1979

2. Optimistic Methods for Concurrency Control in Distributed DatabaseSystems 1981

3. Problems of Optimistic Concurrency Control in Distributed Database Systems 1982

4. Concurrency control in database systems: A step towards the integration of optimistic methods and locking 1982

5. Empirical comparison ofdatabase concurrency control schemes 1983

6. Distributed transaction management in jasmin VLDB 1984

7. Observations on optimistic concurrency control schemes 1984

8. Certification by intervals of timestamps in distributeddatabase systems 1984

9. Distributed optimistic concurrency control with reduced rollback 1987

10. A New Distributed Optimistic Concurrency Control Method and a Comparison of its Performance with Two-Phase Locking 1990

11. Concurrency Control in Real-Time Database Systems: Optimistic Scheme vs Two-Phase Locking 1990

12. The End of an Architectural Era 2007

13. Large-scale Incremental Processing Using Distributed Transactions and Notifications 2010

14. Megastore: Providing Scalable, Highly Available Storage for Interactive Services 2011

15. Serializability, not Serial: Concurrency Control andAvailability in Multi-Datacenter Datastores 2012

16. High-Performance Concurrency Control Mechanisms for Main-Memory Databases 2012

17. Speedy Transactions in Multicore In-Memory Databases 2013

18. F1: A Distributed SQL Database That Scales 2013

19. Staring into theAbyss: An Evaluation of Concurrency Control with One Thousand Cores 2014

20. MaaT: Effective and scalable coordination of distributedtransactions in the cloud 2014

21. An Evaluation of Distributed Concurrency Control 2017

22. Carousel: Low-Latency Transaction Processing forGlobally-Distributed Data 2018

OceanBase技術交流羣

想跟本文做者 龍逢 深刻交流嗎？

想認識螞蟻金服OceanBase團隊的一線技術專家嗎？

掃描下方二維碼聯繫螞蟻金服加羣小助手，快速加入OceanBase技術交流羣！