騰訊對分佈式數據庫技術的深度思考與實踐

• 2019 年 10 月 25 日
• 筆記

作者：李海翔，網名「那海藍藍」，騰訊金融雲數據庫技術專家。中國人民大學信息學院工程碩士企業導師。著有《數據庫事務處理的藝術：事務管理和並發訪問控制》、《數據庫查詢優化器的藝術：原理解析與SQL性能優化》、《大數據管理》。

前言

2019年10月11日至13日，CCF數據庫專委會在濟南召開了國內規模最大的、每年一度的數據庫學術盛會——第36屆CCF中國數據庫學術會議（NDBC 2019），騰訊TDSQL團隊受邀在「數據庫產學研合作論壇」，做了主題為「TDSQL對未來分佈式數據庫的技術研發思考與實踐」的技術報告，與國內數據庫學界與業界核心技術人員共同探討國產數據庫面臨的基礎問題和技術發展方向，助力推動我國數據庫技術自主可控發展。

與此同時，本次會上，騰訊雲數據庫技術專家、金融級分佈式數據庫TDSQL團隊專家工程師、中國人民大學信息學院工程碩士企業導師李海翔，當選成為了中國計算機學會（CCF）數據庫專委會委員。未來，騰訊將加大投入，促進我國數據庫產學研合作，推進數據庫技術自主可控發展。

本次會議上，騰訊TDSQL團隊帶來了TDSQL對分佈式數據庫技術研發的深度思考與實踐分享，主要包括三個方面：

1） 分佈式事務的效率與正確性，如何在保證雙一致性（事務一致性、分佈式一致性）的前提下，提高分佈式事務型集群的處理效率？ 2） 新硬件和AI等技術，在雲環境下，如何影響着數據庫的架構？ 3）數據庫各個模塊間是否能解耦以降低研發的複雜度，同時縮短研發人才的培養周期？

騰訊TDSQL數據庫的發展歷程

TDSQL是騰訊打造的金融級分佈式數據庫，對內支撐騰訊公司近90%的金融、交易、計費類業務。2007年，隨着公司業務再一次騰飛，TDSQL團隊啟動了一個7*24高可用服務項目，以保障騰訊計費等公司級別敏感業務高可用、核心數據零丟失、核心交易零錯賬。這也是TDSQL的前身。

然而，考慮到當時選用的技術方案，技術層與業務層耦合較深。於是，騰訊技術團隊開始了研發一款金融級數據庫的項目。實現讓數據庫來解決高可用、數據一致性、水平伸縮等問題，而讓業務系統只需要關注業務邏輯。2012年，標準化的金融級分佈式關係型數據庫產品TDSQL研發完成，並在騰訊內部大規模推廣使用。

十多年研發演進中，TDSQL在高可用、分佈式方面做持續優化，同時不斷提高性能，具備全球部署架構、水平伸縮、企業級安全等特性。

例如，2018年，TDSQL實現了原創性提出的全面地解決讀一致性的算法，使得分佈式事務的一致性和分佈式系統的一致性統一在一起。同年，在業界頗為頭疼的雲數據庫運維問題上，TDSQL還提供了兩大利器：「赤兔」運營管理平台和「扁鵲」智能DBA診斷系統。

從2014年開始，TDSQL通過騰訊金融雲平台對外開放。目前TDSQL已經為500+機構提供數據庫的公有雲及專有雲服務，客戶覆蓋計費、第三方支付、銀行、保險、互聯網金融、物聯網、互聯網+、政務等領域，助力客戶業務從國際數據庫切換為自主可控的分佈式數據庫。

今年，騰訊雲TDSQL助力張家港行成功將銀行傳統核心系統由集中式數據庫存儲改造為分佈式數據庫存儲，這是在國內銀行首次在傳統核心業務系統場景下，採用國產分佈式數據庫，打破了該領域對國外數據庫的長期依賴。

TDSQL的分佈式事務處理技術

首先，我們分享一下TDSQL在實現「雙一致性（事務一致性、分佈式一致性）」，並提高分佈式事務型集群的處理效率的探索實踐。

眾所周知，數據庫是一個高並發系統，所有的操作通過事務的語義加以約束。而事務的語義，表現為事務的四個特性——ACID：原子性（A）、一致性（C）、隔離性（I）、持久性（D）。而一個數據庫系統，其最核心的技術，就是事務處理技術。為了保障ACID，數據庫使用了多種複雜技術，其中，技術的核心是並發訪問控制算法。

事務處理技術，有兩個初衷：一是數據正確性，二是並發高效率。TDSQL的分佈式事務處理模型，經歷了2代，第一代採用的技術是2PL+MVCC，第二代採用的是OCC+2PL+MVCC。OCC技術融合了2PL以解決高衝突不能高效率的問題，OCC融合了MVCC消除了讀寫、寫讀互相阻塞的並發問題進一步提高了性能，自適應的OCC使得在OCC和2PL間動態自動切換，使得分佈式事務處理機制更聰明。

但是，這些還不足以體現TDSQL如何着手提高分佈式事務的效率。在架構上，TDSQL是去中心化的架構，沒有集中式單Master那樣的處理分佈式事務的單點瓶頸，事務協調器間傳遞相關聯的分佈式事務控制信息量被優化，分佈式並發訪問控制算法的衝突粒度控制在數據項一級從而提高了事務的並發度，因而效率更高。另外還有很多其他方面的優化，使得TDSQL的分佈式事務處理效率較高。

而我們繼續探討，如圖1，在分佈式背景下，怎麼實現「雙一致性（事務一致性、分佈式一致性），並提高分佈式事務型集群的處理效率？

圖1實現分佈式事務面臨的問題

該問題，是業界一個難題。Google的Spanner系統實現了雙一致，但事務處理的效率很低。TDSQL在深入研究分佈式事務處理的技術時，不僅解決了全局一致性問題（2019DTCC大會分享：分佈式數據庫全局讀一致性），而且提出了一個「統一致性模型」，不僅在正確性上實現了雙一致的功能，而且高效地解決了該問題。

在TDSQL看來，雙一致性的正確性相對容易實現（儘管這也是一個很難解決的問題），但分佈式事務型數據庫的性能難以有效提高。

那麼，有哪些因素，制約着分佈式事務型數據庫性能的提高呢？

如圖2，一些研究者認為，是網絡帶寬限制了性能；一些研究者認為，制約分佈式事務型數據庫性能的提高有2個因素，一是「latency」本身，二是「latency」延長了事務的生命周期，而長的事務生命周期導致並發事務發生衝突的概率增大，進而引發事務回滾降低了性能。

圖2 分佈式事務的瓶頸

另外，影響正確性和性能的，是事務處理技術中的核心技術——並發訪問控制算法。

如圖3所示，實驗表明，在事務型數據庫中，OCC算法效率更高，在多核環境下，OCC算法比2PL算法性能高出170倍。但是，高的並發衝突下，OCC的回滾率增加，表明OCC算法的缺點也很明顯。

圖3 並發訪問控制算法的優劣

但是，還有研究者對於多種並發訪問控制算法進行了較驗證，如圖4，發現傳統的OCC算法比很多種知名的改進的OCC算法（如知名的Tictoc、自適應的OCC等算法）更有效。這表明，不同人實現的不同的系統儘管採用了一樣的算法思路，但是實際效果卻大不相同（如Tictoc自身的測試結果表明其改進的OCC算法效率好於傳統的OCC算法）。所以，我們在思考，不同實驗得到不同的結論，其背後，真的影響分佈式事務的效率的因素究竟是什麼？

圖4 多種並發訪問控制算法的比較之一

進一步探討，如圖5所示，不同研究者表明，自適應的OCC（OCC+2PL），有着更好的性能（圖5中間的子圖）。綜合圖3、圖4和圖5，其實可以發現，不同的研究者的驗證結果，是不能互相推證的，他們的驗證結果，只能表明算法之間的大致趨勢（如OCC性能會比2PL更好一些）差異，但不能精確表明算法之間的差異點究竟在哪裡。

圖5多種並發訪問控制算法的比較之二

再對比圖6，騰訊在MySQL上做了熱點更新功能，發現在高並發高競爭同一個數據項的情況下，影響MySQL性能的，不是2PL這個算法本身，而是為解決死鎖問題時死鎖檢測算法消耗的CPU資源，故MySQL的事務吞吐量近乎為0。禁止了死鎖檢測後，並用系統鎖（非事務鎖）互斥了在同一個數據項上的並發競爭後，MySQL系統事務處理吞吐量上升的萬倍左右。

圖6 真實系統下的真實問題

這說明了，在不同系統下實現的相同算法的結果，只具有參考價值。如果在實際系統中，如MySQL、PostgreSQL中做實現，才更有實際參考意義。

分佈式數據庫的架構與解耦

TDSQL團隊在研發分佈式事務型數據庫的過程中，除了思考分佈式事務處理技術（ACID實現的所有技術）外，還深度探索測試驗證、架構擴展、模塊解耦等等各種重要的問題。

新硬件和AI等技術，在雲環境下，如何影響着數據庫的架構？

數據庫各個模塊間是否能解耦以降低研發的複雜度，同時縮短研發人才的培養周期？

新硬件和AI等技術，從架構上深深地影響了傳統的數據庫，這表現在如何融合這些新技術：

• 首先，數據庫可能會「增加」很多新模塊進去，如圖7中的左下子圖，AI調優數據庫技術使得數據庫系統被擴展了，增加了很多新組件進來。
• 其次，數據庫的傳統模塊會被改變，如圖8中的左下子圖，在並行的事務型數據庫系統中，提出基於AI技術對事務進行優化的模型。該模型採取存儲過程的方式（此點類似H-Store、VoltDB），向數據庫引擎提前提供所執行的事務，然後利用AI技術（Markov model，馬爾可夫模型）對存儲過程進行分析，確定那些存儲過程所代表的事務間的語義，排定事務並發執行時哪些是互相衝突的，得到一個有固定結構的事務執行模型，如圖8左下子圖中右側，是對TPC-C模型NewOrder進行的分析得到的事務調度圖。

當多個Client發出SQL語句執行存儲過程代表的並發事務時，據此模型即能推斷事務的調度方式。這是AI技術改變事務處理中並發訪問控制模塊的一個典型事例。

圖8中的右上子圖，是RDMA對於事務處理技術的影響，該圖展示了四種模型，其中「d」模型是基於RDMA從2個方面對事務處理構成影響，一是事務處理的控制流，二是事務執行過程中發生的數據流。影響分佈式事務處理效率的，不僅僅是龐大的數據流，而相對數據量小的控制流，也是瓶頸，因此需要引入RDMA來加以解決網絡帶寬瓶頸。

圖7 數據庫架構發生變化

圖8 數據庫中的模塊發生變化

傳統的數據庫系統，其複雜度極高，從外看高內聚，從內看高耦合，這使得數據庫的複雜度驟然提升。當各種新技術產生，影響了數據庫的架構時，數據庫的複雜性被再提上一個台階。在這種背景下，研發人才的培育，其成長周期就會更長。因此，我們在思考的一個問題是：從技術上看，如何解耦數據庫內部間的諸多模塊？耦合度高，研發人員需要掌握數個相關模塊才能良好推進工作；如果模塊間解耦較好，掌握單個模塊就能方便推進工作，這樣人才的培育周期相應也會縮短，軟件的質量也會得到提高。

所以，數據庫架構背景下各個模塊解耦問題，是一個技術問題。解耦工作，可以在許多層次、許多模塊間展開。解耦技術，各有其妙。

如圖7右上子圖所示，AWS的Aurora提出的存儲計算分離，就是存儲和計算兩大模塊的解耦。而微軟Deuteronomy系統在08年-16年也有過一系列相關工作。Deuteronomy一開始採用的方案是在存儲層上面實現事務，而底層的存儲採用的是KV模型。存儲層只需要提供KV的原子性和冪等性，上層就可以比較容易實現事務的並發訪問控制和恢復。後來的Percolator、Spanner/F1、CockroachDB、TiDB其實也是沿着這個思路在發展，底層是Bigtable/Spanner或者RocksDB這樣的KV存儲引擎，在存儲之上封裝一層事務。但是在類似RocksDB這樣的KV存儲中，對於KV記錄的並發控制還是和存儲緊耦合的。

存儲和計算兩大模塊的解耦，促進了各自所囊括的子模塊之間再次進行解耦，如圖9所示，事務和存儲層的解耦，該怎麼進行？有的研究者，把事務處理功能提取到客戶端進行（圖9左子圖），有的把事務處理功能放到中間件層實行按（圖9中間子圖），這2種方式不同於傳統的在Server端進行事務處理（圖9的右子圖）。

圖9 事務和存儲層解耦

另外，解耦工作，其實無處不在。圖10展示了算法與數據結構之間的解耦。圖10的左子圖，是數據庫的持久化部分和內存中數據之間的設計解耦。圖10的右子圖，是索引的數據結構與物理存儲層之間的解耦。

圖10的左子圖，對應VLDB 2018的論文"FineLine: Log-structuredTransactional Storage and Recovery"，提出了一種事務存儲和恢復機制FineLine，捨棄了傳統的WAL，把所有需要持久化的數據存儲到一個單一的數據結構，希望將數據庫的持久化部分和內存中數據存儲之間達到設計解耦。

FineLine無需將內存中數據落盤到DB，僅將內存中的log信息持久化到Indexed log中，然後通過fetch操作從Indexed log讀取到數據的最新狀態。通過將內存中的數據結構與其持久性表示盡量地解耦，消除了與傳統基於磁盤的RDBMS相關的許多開銷。除此之外，這種單一的持久化存儲架構帶來的另一個好處是，在系統發生故障後恢復的開銷很低。由於Indexed log保持了與原子操作的一致性，當發生故障並重啟時，可以從Indexed log中讀取到已提交的最新數據記錄。基於no-steal的策略，Undo操作，Checkpoint這些也都不需要。

圖10 計算與數據結構之間的解耦

數據庫內部，各個模塊之間的解耦，與模塊粒度的劃分，與具體實現的系統，都有密切關係。如圖11展示了幾個主流數據庫之間解耦的關係，期待能拋磚引玉，引發更多思考。

圖11 主流數據庫解耦的比較

結語

數據庫作為核心基礎技術之一，在自主可控的時代發展潮流下，是我們必將要跨過的大山。路雖彌，不行則不至，歷經十數年的研發演進，至少今天我們都已達成了許多重要的里程碑。當下而言，國產數據庫從技術、人才、工業生態等各方面，都有待完善和發展，而未來更緊密的產學研結合、科技與傳統產業融合趨勢下，將進一步促進數據庫自主可控發展。

江湖召集令

9月27日-11月6日，騰訊雲數據庫王者挑戰賽（點擊查看詳情） 等你挑戰！花幾分鐘參加比賽免費將☟☟抱回家！

• MacBook/iPhone 11/AirPods
• 25台Kindle
• 8萬元騰訊雲創業基金
• MySQL之父 Michael Widenius 面對面交流

轉發下方海報參與活動可以獲得騰訊公仔和騰訊雲數據庫無門檻代金券，詳情請掃描下方圖片二維碼諮詢。

 比賽詳情&報名入口

請掃下方二維碼

瘋狂11.11

10月21-31日，騰訊雲MySQL低至1.5折起，7元/月；SQL Server全場2折，91元/月，企業新用戶及個人新用戶可領取千元代金券。

，

↓↓點擊閱讀原文購買