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

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

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

concurrent6
Megastore是少有的在核心層實現OCC的生產級分散式資料庫系統，在Entity Group的資料分割槽級別使用MVOCC實現了序列化隔離級別的事務，同一分割槽一次只能執行一個事務，分佈多副本間可以併發執行事務。一個OCC事務三個階段的實現大致描述如下：

1. 讀取階段
① 在任意副本均可發起強一致讀；資料更新快取在應用的事務私有記憶體
② 從多數派副本中獲取最新事務提交時間戳及事務日誌的位置（可以透過查詢本地coordinator中副本的資料狀態做最佳化）
③ 選擇一個合適的副本（綜合考慮本地性、響應時間、事務提交時間等），使用Paxos協議同步事務日誌並將其應用到本地Bigtable中
④ 若選擇了本地副本，則非同步更新coordinator中副本資料狀態為有效
⑤ 根據獲取的事務提交時間戳從本地Bigtable中讀取資料

2. 驗證階段
① 從強一致讀得到的事務日誌中獲取下一次寫入事務日誌的位置
② 選取一個比最新事務提交時間戳更大的值作為本次事務提交時間戳
③ 將事務私有記憶體中的更新打包到一個事務日誌中
④ 發起一次完整的兩階段Paxos協議例項（可以最佳化為一階段Paxos協議），一個事務日誌位置只能由一個事務提交成功。如果成功，則將未成功接受當前事務日誌的副本所對應的coordinator中的資料狀態設定為失效，通知應用事務已提交；如果失敗（prepare階段發現提交的內容與達成一致的內容不匹配），則終止事務並重新執行

3. 寫入階段（非同步執行）
將更新資料非同步寫入 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，讀時間戳如果比事務提交時間戳小，則可見

2.  準備階段（驗證階段）
① 獲取當前時間戳作為提交時間戳，事務狀態設定為preparing
② 讀集有效性驗證，檢查讀集中的版本是否依然可見；重新執行掃描集檢查是否存在幻讀
③ 等待提交依賴全部完成或當前事務是否已被其它事務設定為中止
④ 同步寫redo日誌
⑤ 將事務狀態設定為commited

3.  後處理階段（寫入階段）
① 如果提交，將新資料的begin域和舊資料的end域設定為提交時間戳
② 如果中止，將新資料的begin域設定為無效，嘗試將舊資料的end域設定為無效（如果已被其它事務更新則忽略）
③ 處理提交依賴，如果提交，則減少依賴該事務的其它事務的提交依賴計數；如果中止，則通知依賴該事務的其它事務中止
④ 清理事務表

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

F1: A Distributed SQL Database That Scales VLDB 2013
F1是Google內部研發的分散式關聯式資料庫，儲存層基於Spanner，自建SQL層，用於Google最重要的廣告業務。F1在Spanner之上基於行級的修改時間戳列實現了樂觀事務並將其設定為預設配置，論文提到使用樂觀事務有如下優缺點：
• 優點
– 容忍客戶端的不正確行為（如無意義的長事務或未正常結束的事務）
– 長事務/互動式事務友好（沒有鎖超時導致中止的問題/使用者查詢期間不持有鎖）
– 服務端重試友好，對使用者透明
– 事務更新狀態儲存在客戶端，利於容災及負載均衡
– 易於實現投機寫（檢查讀資料的版本變更發現衝突）
• 缺點
– 幻讀問題需要藉助其它手段避免
– 高資料競爭場景下的低事務吞吐率
其中關於 OCC優點的描述來自生產級分散式環境運維的最佳實踐經驗，雖然只是應用層的簡單實現，但也從另一方面驗證了OCC在現代分散式資料庫環境中的技術價值。

 

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