以時間軸的方式對不同時期的有代表性的論文（從理論研究、原型系統、 生產系統三個維度分類）進行了梳理，帶你簡要回顧一下 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]中所述，多核（幾十、幾百）、大記憶體（T級別）的單節點配置已在市場上出現， 意味著大多數OLTP場景下的資料處理可以完全執行在記憶體中，SAP HANA、MemSQL、TimesTen、SolidDB、Hekaton等記憶體資料庫也應運而生。

• 分散式NewSQL資料庫
隨著網際網路應用的興起，標榜著高可靠、高可用、高可擴充套件的 NoSQL運動席捲而來， 執行環境也由大型機過渡到分散式叢集、多資料中心、多可用區等；NoSQL系統雖然實現了承諾的目標， 但其不支援SQL語言、缺乏強一致性的短板一直備受開發人員的抱怨，於是NewSQL系統又進入了人們的視野， 其主打口號是既具有NoSQL的所有優點並且還支援SQL語言及ACID事務，如F1、Spanner、CockroachDB、TiDB、OceanBase等。

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

上述兩種場景，一個關注單機事務吞吐量；另一個關注分散式事務吞吐量，其效能最佳化目標可以統一描述為在硬體資源充足的情況下如何提高事務吞吐量。節約資源已不再是重點，減少系統同步，提高資源利用率才是核心問題。尤其是在分散式計算環境下，網路互動的延遲或異常容易導致 2PL協議可能長時間持有鎖從而導致系統整體事務吞吐率降低或死鎖。OCC的價值在新的資料庫基礎設施環境上又獲得了學術界與工業界的重視。

 

以上為分散式技術專題之併發系列三：樂觀併發控制之原型系統， 「分散式技術專題」是國產資料庫 hubble 團隊精心整編，專題會持續更新，歡迎大家保持關注。