在數字化時代，作爲基礎軟件，數據庫的自主可控對於企業的數據安全、業務穩定具有重要意義。只有實現“自主可控”才能從根本上保證信息安全，尤其是涉及重大安全的政府和金融領域，對數據安全的要求進一步加強。因此，在互聯網安全上升至國家戰略層面的背景下，如何在底層基礎數據庫層面實現自主可控成爲雲計算廠商不斷追求的目標。
基於微信支付/紅包的複雜業務場景，騰訊一直致力於實現數據庫的自主可控，保證數據強一致性、高可用和水平擴展。實際上，騰訊推出的TDSQL(TencentDistributed SQL)金融級分佈式數據庫，在對內支撐微信紅包業務的同時，對外也正在爲中國金融行業技術自主可控分佈式數據庫解決方案
作爲國內首家互聯網銀行，微衆銀行背後的IT基礎架構拋棄了傳統的IOE，完全採用了互聯網分佈式架構。從2014年開始，騰訊雲開始爲微衆銀行提供核心交易數據庫解決方案。TDSQL在微衆銀行作爲交易核心DB，部署超過800個節點，承載全行所有OLTP業務。由於完全採用互聯網架構，相比傳統的IOE方案，微衆銀行在IT成本上大幅節約。同時，互聯網架構的高伸縮性，使得微衆銀行的服務能力具備很高的彈性，足以輕鬆應對普惠金融場景下的潮涌。
“2017年微衆銀行將每個賬戶的運營成本降至平均只有6元人民幣，僅爲內地傳統銀行的1/10，相比國際銀行則更低，只有其成本的2%至5%。” 微衆銀行副行長兼CIO馬智濤說。
目前TDSQL已正式通過騰訊金融雲對外輸出金融級分佈式數據庫產品服務，除了微衆銀行，騰訊分佈式數據庫TDSQL還支撐着華通銀行、華夏銀行、濰坊銀行、內蒙金谷農商銀行、北京人壽、愛心人壽等衆多銀行和保險公司的互聯網核心生產系統。並已經爲超過500+的政企和金融機構提供數據庫的公有云及私有云服務，客戶覆蓋銀行、保險、證券、互聯網金融、計費、第三方支付、物聯網、互聯網+、政務等領域，得到了客戶及行業的一致認可。
那麼在市場業務環境變化的場景下，TDSQL是如何實現自主可控和技術迭代的呢？下面我們從TDSQL的架構演進來具體分析。
業務場景爆發推動數據庫進化
從架構上講，TDSQL是Shared-Nothing架構的分佈式數據庫；從部署方式來講，TDSQL是一款支持多租戶的雲數據庫；從能力上講，TDSQL比當前流行HTAP更進一步，它重新定義了一種綜合型的數據庫解決方案，也可以分配Noshard實例、分佈式實例和分析性實例，同時支持JSON/RockDB等方案。當然，TDSQL最主要的特點在於其具備shard架構能力。
在2004年，騰訊充值、財付通等業務爆發發展，但那時騰訊和所有的創業公司有個共同點—“窮”，在這樣的背景下，TDSQL逐步誕生了，所以騰訊金融類業務從一開始就沒有IOE。
因爲期間經歷了業務層對拆分的濫用，主從數據不一致導致的數據準確性問題，以及上百臺設備集羣的管理問題等。
所以，從08年開始，團隊決定重構TDSQL解決方案，針對金融類業務的特點，列出以下幾個要點：
λ 數據強一致的要求
λ 數據庫集羣的可用性、穩定性和容災要求要達到銀行標準
λ 業務無需拆分超大表，數據庫自動拆分
λ 接入要簡單，老業務改造要小，必須兼容MySQL協議
λ 符合並高於金融行業信息安全監管要求
TDSQL的軟件架構組成
整體來說，TDSQL是由決策調度集羣/GTM，SQLEngine、數據存儲層等核心組件組成的，其每個模塊都基於分佈式架構設計，可以實現快速擴展，無縫切換，實時故障恢復等，通過這一架構，TDSQL的Noshard、Shard、TDSpark實例可以混合部署在同一集羣中。並且使用簡單的x86服務器，可以搭建出類似於小型機、共享存儲等一樣穩定可靠的數據庫。
在架構上，TDSQL的核心思想只有兩個：數據的複製（replica）和分片（sharding），其它都是由此衍生出來的。其中，
•replica配合故障的檢測和切換，解決可用性問題；
•sharding配合集羣資源調度、訪問路由管理等，解決容量伸縮問題。
同時，因replica引入了數據多副本間的一致性問題和整體吞吐量下降的問題，而sharding的引入也會帶來一定的功能約束。
在最終實現上，TDSQL由Scheduler、Gateway、Agent三個核心組件加上MySQL組成，其中：
•Scheduler是管理調度器，內部又分爲zookeeper和scheduler server；
•Gateway爲接入網關，多個網關組成一個接入層；
•Agent是執行代理，與MySQL實例一起，構成數據節點。多個數據節點構成服務單元SET。
相比單機版的MySQL，TDSQL的優勢主要體現在集羣維度，包括容災、高一致性、高彈性等。
注：✔ 支持，✘不支持， ○不適用
數據一致性考驗
在金融行業，銀行、風控、渠道等第三方通常通過讀寫分離方式來查詢數據，而在互聯網行業，由於x86相對較高的故障率，導致數據可能經常性的出現錯亂、丟失場景。爲了解決這個問題，就必須要求主從數據的強一致和良好的讀寫分離策略。其關鍵在於，如何實現強同步複製技術。
由於MySQL的半同步和Galera模式不僅對性能的損耗是非常大的，而且數據同步有大量毛刺，這給金融業務同城雙中心或兩地三中心架構容災架構帶來了極大的挑戰。
爲什麼會這樣呢？從1996年的MySQL3.1.1.1版本開始，業務數據庫通常跑在內網，網絡環境基本較好，因此MySQL採用的是每個連接一個線程的模型，這套模型最大的好處就是開發特別簡單，線程內部都是同步調用，只要不訪問外部接口，支撐每秒幾百上千的請求量也基本夠用，因爲大部分情況下IO是瓶頸。
但隨着當前硬件的發展，尤其是ssd等硬件出現，IO基本上不再是瓶頸，如再採用這套模型，並採用阻塞的方式調用延遲較大的外部接口，則CPU都會阻塞在網絡應答上了，性能自然上不去。
因此，TDSQL引入線程池，將數據庫線程池模型(執行SQL的邏輯)針對不同網絡環境進行優化，並支持組提交方案。例如，在binlog複製方案上，我們將複製線程分解：
1、任務執行到寫binlog爲止，然後將會話保存到session中，接着執行下一輪循環去處理其它請求了，這樣就避免讓線程阻塞等待應答
2、MySQL自身負責主備同步的dump線程會將binlog立即發送出去，備機的io線程收到binlog並寫入到relaylog之後，再通過udp給主機一個應答
3、在主機上，開一組線程來處理應答，收到應答之後找到對應的會話，執行下半部分的commit，send應答，綁定到epoll等操作。綁定到epoll之後這個連接又可以被其它線程檢測到並執行
改造後，使得TDSQL可以應對複雜的網絡模型。當然，深入瞭解過MySQL同步機制的朋友可能會發現上述方案還有小缺陷：當主機故障，binlog沒有來得及發送到遠端，雖然此時不會返回給業務成功，備機上不存在這筆數據，然而在主機故障自愈後，主機會多出來這筆事務的數據。解決方法是對新增的事務根據row格式的binlog做閃回，這樣就有效解決了數據強一致的問題。
2018年初，英特爾技術團隊使用sysbench測試方案，在跨機房、相同機型、網絡和參數配置和高併發下測試，TDSQL強同步複製平均性能是MySQL5.7異步複製的1.2倍。
基於規則和基於代價的查詢引擎
當前大多數分佈式數據庫都設計的是基於規則的查詢引擎(RBO)，這意味着，它有着一套嚴格的使用規則，只要你按照它去寫SQL語句，無論數據表中的內容怎樣，也不會影響到你的“執行計劃”，但這意味着該規則複雜的數據計算需求不“敏感”。雖然金融業務都有自己的數據倉庫，然而也會經常需要在OLTP類業務中執行事務、JOIN甚至批處理。
TDSQL在SQLENGINE實現了基於代價的查詢引擎(CBO)，SQL經過SQLENGINE的詞法，語法解析，語義分析和SQL優化之後，會生成分佈式的查詢計劃，並根據數據路由策略（基於代價的查詢引擎）進行下推計算，最後對彙總的數據返回給前端。
而作爲分佈式的計算引擎，在存儲與計算引擎相分離的情況下，非常重要的一環就是如何將計算儘量下推的下面的數據存儲層。因此TDSQL的SQLENGINE在經過大量業務打磨後，實現了基於shard key下推，索引條件下推，驅動表結果下推，null下推，子查詢下推, left join轉化成inner join等多達18種下推優化手段，儘量降低數據在多個節點傳輸帶來的壓力，以提供更好的分佈式查詢的能力，支撐金融交易的關聯操作。
全局事務一致性與全局時間戳服務GTM
金融行業對事務處理的需求極高，轉賬、扣費，無一不是使用事務，而騰訊是少數幾個將分佈式事務處理，分佈式JOIN用於金融核心系統的企業。
TDSQL仍然是通過經典的XA兩階段提交加兩階段封鎖協議實現了強分佈式事務的語義，以支撐金融場景對事務管理的需求。在使用語法上與MySQL完全一樣，即後端的分佈式事務處理對業務使用方是完全不感知，以保證兼容性。
在二階段提交實現上，在begin的時候從GTM獲取全局遞增的事務ID，然後在參與事務的各個子節點通過這個事務ID開啓事務，進行各種DML操作，提交的時候先對各個子節點執行prepare。當prepare成功之後，再更新全局事務ID的事務狀態，同時獲取到一個新的事務ID作爲提交的事務ID對各個子事務進行異步並行化的提交，提供更好的事務操作性能。
當前GTM以一主兩從的方式運行，主從節點底層通過 raft 協議進行數據的同步以及主從切換，內部交互以及對外通訊均基於 grpc 協議。當前TDSQL的GTM組件性能完全可以滿足金融業務需求：
λ 全局時間戳：≈180w - 190w TPS，8 Clients，主節點CPU 跑滿情況下（24core），內存消耗約23GB；
λ 遞增序列號：≈750w - 780w TPS，8 Clients，10萬個 key，主節點 CPU 跑滿情況下 ，內存 消耗約30GB；
從節點資源消耗：因爲所有請求均由Leader節點完成響應，從只負責接受來自於 主節點的 raft 數據同步請求，並且 從節點上不緩存任何數據，因此 CPU 和 內存消耗都在極低的程度；因此，一般場景下，通常GTM與調度決策集羣可以混合部署，極大的節省了物理設備成本。
TDSQL的HTAP能力
TDSQL除了提供計算下推，分佈式事務等特性，也針對OLAP需求演進了TDSpark特性。
簡單來說，是將SQLEngine基於OLAP場景做了修改，保留原生的MySQL協議接入能力。因此業務繼續可以通過訪問MySQL的渠道接入到OLAP-SQLEngine，OLAP-SQLEngine在這個時候不是將分佈式的查詢計劃直接下推到各個數據庫節點，而是引入一箇中間層，目前是採用SPARKSQL,通過SPARKSQL強大的計算能力能顯著提升複雜SQL的執行性能。另外爲了確保分析操作與在線的OLTP業務隔離，我們TDSQL的數據層爲每份數據增加1個watch主數據庫的數據異步節點，確保分析操作與在線業務操作不互相影響。
數據安全與容災
數據安全和容災是金融類業務的命脈，而TDSQL現已經應用在多個銀行、保險的公有云或私有云環境。符合國家等級保護信息安全要求，通過銀保監會相關審覈，獲得了包括ISO，SOC等國內和國際標準。
而在容災能力方面，TDSQL可以支持：
λ 同城數據強一致下的雙活：當前騰訊公有云和金融雲有大量的客戶都選擇了類似方案。
λ 主從讀寫分離的異地多活：該方案適用於應用完全不做任何改造，就可以實現跨城多活的能力。當前TDSQL很多客戶不想對業務改造，但是又想具備跨城多活和切換的能力，通常選擇這個方案。
λ 多主的異地多活架構，並支持雙向同步：通過應用層根據用戶維度做了區分之後，可以使得多套TDSQL數據庫分別承載不同的業務進行讀寫事務訪問，實現完全的多活能力，但是如果業務系統無法保證調度安全和數據的區分，可能存在數據異常的風險。
多主的異地多活架構，多套主從架構：綜合了前面兩種架構，實現了完全的異地多活+讀寫分離的能力，並且即使業務層路由錯誤，也不會引起數據異常。當然，對應的應用層也要能配合修改。
當然越高要求對部署的要求約複雜，目前公有云已經提供了前面兩種方案可供大家試用。
數據庫自治運營
爲了保證系統的運行做到一切盡在掌控之中，TDSQL不僅有完善的管控系統（赤兔）來完成系統的自動化管理，從可用性、安全、效率、成本維度進行全方位管控。還在赤兔中引入了“數據庫自治運營”的理念，構建了一套能自我學習的智能檢測平臺（簡稱扁鵲）
以SQL優化爲例，該系統能自動抽象出當前效率最差的若干SQL，並將這些通過解析SQL生成AST語法樹，分析語法樹中表的連接方式和連接字段，然後遍歷語法樹中的過濾，排序等關鍵字段，再次分析各字段的區分度，對於區分度較高的字段會提供推薦優化方案，綜合字段區分度，過濾規則，表連接順序等多個因素推提供優化建議。
TDSQL的自治運營的最終目標是利用公有云龐大的環境進行自我學習和自我進化，做到無需人工干預即可進行更新、調整和修復，從而解放人力、減少人爲差錯，幫助企業節約管理及經濟成本、降低風險。
金融業務的數據庫發展及展望
金融業務涉及國計民生的重點業務，一個小小的BUG，一個操作失誤，就可能影響到數以萬計的百姓資產準確性。正因爲這樣的責任，騰訊雲TDSQL團隊始終堅守則“本心”。
目前，TDSQL已在北京、深圳、成都三地建立研發團隊，並通過CMMI3認證，同時在開源社區擁有自己的開源分支。值得一提的是TDSQL已獲得包括ISO27001、ISO22301、PCI DSS、SOC審計，工信部分佈式數據庫測試，IT168技術突破大獎，多項國家或國際認證和行業殊榮。並與包括中國人民大學，中國銀行等開展產研結合、產用結合，並取得諸多創新成績。
展望2019年，TDSQL將持續通過產研結合、產用結合的方式進行研發突破，並開放商用更多特性，擁抱開源社區。