「分散式技術專題」併發系列三:樂觀併發控制之原型系統(動態調整提交時間戳)
原型系統 ——動態調整提交時間戳減少事務中止率
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]並在系統實現上進行了最佳化,其基本思想如下:
concurrent7
基本資料結構:
• 在事務訪問的每個結點上需要維護記憶體事務表,記錄事務的提交時間戳區間及當前狀態- (runing/validated/committed/aborted)
• 每個資料物件維護一個最大讀時間戳和最大寫時間戳,這些時間戳均為已提交事務的提交時間戳
• 每個資料物件維護讀/寫過該物件的活躍事務號
基本流程:
1.讀取階段
① 在事務請求結點上分配一個全域性唯一事務號,並在記憶體事務表中初始化事務資訊(提交時間戳區間設定為0到正無窮,狀態設定為running)
② 事務執行過程中第一次訪問任意遠端結點上的資料時都需要在結點本地的記憶體事務表中建立事務相關初始資訊
③ 根據讀寫型別區別操作
讀操作
– 將事務號加入讀物件的未提交讀事務號列表
– 返回讀物件資料、讀物件上當前加寫鎖的活躍事務號及讀物件的最大寫時間戳(事務提交時需保證提交時間戳小於所有該物件上寫事務的時間戳並大於最大寫時間戳)
– 客戶端將返回資料快取在事務私有記憶體中
寫操作
將更新資料寫入客戶端的事務私有記憶體中
2.驗證階段
① 客戶端傳送預寫/驗證訊息到所有相關資料伺服器(讀寫涉及到的伺服器),訊息中包括與伺服器相關的讀集、寫集及在讀取階段從伺服器獲取的資訊(所有在讀物件上加寫鎖的活躍事務號及最大寫時間戳)
② 預寫(處理伺服器上的寫操作)
收到訊息的伺服器將事務號加入寫物件的未提交寫事務列表
寫事務日誌
獲取在寫物件上加讀鎖的活躍事務號及最大讀提交時間戳(事務提交時需保證提交時間戳大於所有該物件上讀事務的時間戳並大於最大讀時間戳)
獲取在寫物件上加寫鎖的活躍事務號
③ 驗證(保證事務的序列化順序按提交時間戳排序,透過調整事務提交時間戳區間的上下限實現,調整的原則為儘量減少事務中止率)
對於讀集中的物件,需要保證驗證事務能在讀物件的最大寫時間戳之後提交
對於讀物件上的加寫鎖事務,需要保證在驗證事務之後提交
對於寫集中的物件,需要保證驗證事務在寫物件的最大讀時間戳之後提交
對於寫物件上的加讀鎖事務,需要保證在驗證事務之前提交
對於寫物件上的加寫鎖事務,需要保證在驗證事務之後提交
④ 驗證結束後,如果驗證事務的提交時間戳區間有效(下限小於等於上限),則將事務狀態改為validated;否則,將事務狀態改為aborted
⑤ 各結點通知客戶端事務狀態及調整後的提交時間戳區間
3.寫入階段
① 如果有結點返回aborted,則事務最終狀態為aborted
② 如果所有結點均返回committed,則計算所有提交時間戳區間的交集,區間無效,則事務最終狀態為aborted;否則事務最終狀態為committed,此時客戶端需要從有效區間中選取任意的時間戳作為該事務的提交時間戳
③ 客戶端向相關資料結點傳送事務提交或中止訊息,提交訊息中包含更新資料及確定的提交時間戳
④ 對於abort訊息,資料結點將本地事務表中的事務狀態改為aborted,刪除該事務在資料物件上加過的鎖並記錄事務中止日誌
⑤ 對於committed訊息,資料結點將本地事務表中的事務狀態改為committed,提交時間戳區間設定為客戶端確定的時間戳,刪除該事務在資料物件上加過的鎖並記錄事務提交日誌
⑥ 對於讀集中的資料物件,如果事務提交時間戳大於讀物件的最大讀時間戳,則將讀物件的最大讀時間戳設定為事務提交時間戳
⑦ 對於寫集中的資料物件,如果事務提交時間戳大於寫物件的最大寫時間戳,則將寫物件的最大寫時間戳設定為事務提交時間戳並修改寫物件的內容
論文提出的 OCC實現方案被2017年的VLDB論文[21]作為測試OCC效能的參考實現,間接證明這裡提出的OCC演算法已經得到了學術界的認可,雖然論文[21]中對新OCC演算法的效能與其它併發控制演算法的比較仍然沒有正面評價,但效能瓶頸已經轉移到網路傳輸及CPU計算消耗,事務中止率及同步開銷已成為效能瓶頸的次要因素,OCC的擴充套件性得到了提高。
以上為分散式技術專題之併發系列三:樂觀併發控制之原型系統(動態調整提交時間戳減少事務中止率), 「分散式技術專題」是國產資料庫 hubble 團隊精心整編,專題會持續更新,歡迎大家保持關注。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70026685/viewspace-2935028/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 「分散式技術專題」併發系列三:樂觀併發控制之原型系統分散式原型
- 「分散式技術專題」併發系列三:樂觀併發控制之原型系統(分散式驗證)分散式原型
- 「分散式技術專題」併發系列三:樂觀併發控制之生產系統分散式
- 「分散式技術專題」併發系列三:樂觀併發控制之理論研究分散式
- 「分散式技術專題」併發系列二:基於時間的併發控制分散式
- 「分散式技術專題」併發系列一:基於加鎖的併發控制分散式
- PostgreSQL 併發控制機制(3):基於時間戳的併發控制SQL時間戳
- Java併發:樂觀鎖Java
- 「分散式技術專題」資料切分與合併分散式
- Java開發技巧——併發控制中的樂觀鎖與悲觀鎖Java
- [分散式][高併發]高併發架構分散式架構
- Java之併發三問題Java
- 高併發核心技術 - 冪等性 與 分散式鎖分散式
- 分散式系統設計中的併發訪問解決方案 | 得物技術分散式
- 併發技術3:定時器定時器
- 併發技術1:CSP併發理論
- 探索併發程式設計(七)——分散式環境中併發問題程式設計分散式
- 併發程式設計之:JUC併發控制工具程式設計
- 分散式鎖不是控制併發冪等的方式分散式
- 高併發技術
- JDK併發AQS系列(三)JDKAQS
- [分散式]高併發案例---庫存超發問題分散式
- 用分散式鎖解決併發問題分散式
- 高併發服務端分散式系統設計概要服務端分散式
- 併發技術5:死鎖問題
- 【作業系統】2.併發控制作業系統
- Guava併發:使用Monitor控制併發Guava
- 併發控制
- GO-併發技術Go
- 併發技術中同步
- go併發之goroutine和channel,併發控制入門篇Go
- ☕【Java技術指南】「併發原理專題」AQS的技術體系之CLH、MCS鎖的原理及實現JavaAQS
- 系統時間的調整
- 【併發技術02】傳統執行緒技術中的定時器技術執行緒定時器
- [分散式]對高併發流量控制的一點思考分散式
- (三)Java高併發秒殺系統API之Web層開發JavaAPIWeb
- 樂觀的併發策略——基於CAS的自旋
- Mysql核心技術:用NOSql給高併發系統加速MySql