原型系統 ——分散式驗證

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

concurrent8

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讀寫不阻塞、沒有死鎖的理念。
相比於前世理論研究的玩具，應用場景的缺乏，今生在記憶體及分散式資料庫場景的落地，理論與工業界不斷地效能最佳化等方面屢有建樹，其技術帶來的實際使用價值正越來越多地得到系統架構設計人員的認可，尤其是在跨分割槽、跨資料中心、跨地域分散式事務，實現序列化隔離級別等現今分散式資料庫尚未深入觸碰的領域有著巨大的挖掘潛力。

結語

本文按照時間線簡要回顧了 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。

 

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