大家好，我是飛哥！

咱們很多讀者都是在互聯網公司工作，大部分同學會有一種認知偏差，總以為互聯網的業務對技術的要求是最高的。但其實不然。

比如在對延時的要求上，高頻量化交易就比互聯網的延遲要求要高得多。在數據庫上，銀行、證券、電信在這些行業中對數據庫的要求也比互聯網高得多。拿銀行舉例，銀行的系統里是連一分錢都不能錯的，而且即使是十幾年前的交易記錄也必須能夠查出來，對安全性的要求就更不用說了。

在過去很長的一段時間里，這些行業選擇數據庫基本上就是 Oracle 和 IBM 的天下，各家企業在選型時基本就是 Oracle 和 DB2 之間二選一。但前幾天看到 IDC 發布了《中國分布式關系型數據庫 2023 年廠商評估》的報告，很高興看到國內數據庫已經發展的非常的好了，老東家騰訊云的 TDSQL 也躋身進了領導者位置，并在國內市場上取得了第一的成績。

IDC 是全球最頂級的市場研究和咨詢機構。它通過大量的數據進行市場分析，對科技行業里的各種技術各家廠商進行分析。為企業提供專業的咨詢服務。這家公司的分析報告是非常權威的，在市場中認可度非常的高。

圖片

那么什么是分布式數據庫，其分布式、強一致性、高可用以及無損升級等特性又是如何實現的呢。今天我們在這篇文中使用 TDSQL 技術架構來進行學習和理解。

傳統的 Oracle 和 DB2 都屬于傳統的單體數據庫架構。由于數據的進一步的大規模的增長，這種傳統架構出現了不少的弊端。一個弊端就是擴展性問題。單機的性能再強存儲再大都不可能承受這些行業里的大規模的存儲和計算需求。

雖然可以通過分庫分表的方式來一定程度提供擴展性，但這種擴展性對應用不透明。應用需要知道底層的集群、庫、表的實現細節，代碼寫起來很臟，后期也不好維護。另一個弊端是存儲和計算沒有分離，總有一個資源是浪費的。

另外還有個更重要的原因是漂亮國脾氣很不穩定，動不動就封鎖咱一下，搞得國內各行各業都擔驚受怕。在銀行、證券、電信這種支柱型的行業里，數據是容不得出一點差錯的。所以近年來，這些行業都在積極地在國內尋找平替產品。

所以數據庫行業需要一些國內的產品出來解決以上問題。

在騰訊早在 2002 年的時候，也主要是使用 Mysql 來存儲騰訊的計費等數據，但后來由于業務的快速發展，用戶量越來越大，增值業務收入規模也越來越大，對可用性的要求水漲船高，就開始自研分布式數據庫，大約到了 2012 年的時候 TDSQL 就形成了雛形，在公司內部提供金融級的高一致性、可靠性的服務。

在 2014 年的時候，騰訊系微眾銀行成立。在做存儲技術選型的時候，經過反復的測試驗證，發現 TDSQL 已經滿足了銀行對一致性、可用性的需求。開始采用 TDSQL 作為核心業務的底層存儲。

后面公有云蓬勃開始發展的時候，TDSQL 自然就作為騰訊分布式關系型數據庫被推向了很多銀行、金融機構。截止到 2023 年，在 4000 多家國內的各種金融、公共服務、電信、證券等行業得到了應用，服務了30家金融機構完成核心系統的替換，中國十大銀行中七家都應用了 TDSQL。

TDSQL 是一個對應用層透明的分布式數據庫。應用可以像使用單機數據庫一樣簡單地使用，不必像分庫分表那樣關心底層的劃分策略。數據庫自己內部封裝事務、分片、災備、擴展性等功能。

圖片

從這個架構圖中可見，用戶請求只需要和負載均衡通信即可，完全不用關心數據庫底層的實現。

而在架構內部主要是三部分組成，一是管理節點、二是計算節點、三是存儲節點。沒錯，現代的分布式存儲都是計算和存儲相分離的。這樣可以做到可以單獨進行擴展。

當有用戶請求到來時，負載均衡組件會把請求發送給 SQL 引擎。從用戶視角來看，它看到的是一張整體上的表。

SQL 引擎會對用戶輸入的 sql 語句進行詞法、語法解析，還需要處理分布式場景下的全局自增字段等邏輯。然后根據 MetaCluster 中存儲的元信息決定將請求發往后面的哪些數據節點。這里要注意的是，用戶訪問的表實際上是可能被分布在后臺的多個 SET 內的，用戶對此并不知情。所以 SQL 引擎會向多個數據節點發起請求，各個節點返回后，SQL 引擎進行聚合后返回給用戶。

這是分布式數據庫的首要目標，對用戶屏蔽分布式，只在邏輯上提供整張的表訪問，簡化用戶使用數據庫的方式。

由于 SQL 引擎只負責計算，不負責存儲，本身是無狀態的。該節點只需要重點關注 CPU 和 內存相關的性能優化即可。在硬件上，也可以選擇計算型的硬件。

SET 是分布式數據庫實例。一個 SET 內部包含了 Master、Slave 節點。每個 SET 中存儲哪些數據是由 shardkey 來進行分散的。在數據接入的時候，TDSQL 采用 raft 協議的強同步復制，Master 接收到業務請求后，等待其中一個 Slave 應答成功后才會返回成功，否則不返回。通過這種方式實現強一致性。

在每個節點內部，都包含一個 Agent 和具體的 Mysql 實例。這種架構有點類似于微服務中 Mesh 架構 中用 Sidecar 把微服務框架功能獨立出來一樣。Agent 和存儲解耦，好處是 Agent 可以監控并上報 Mysql 的狀態，而且系統升級的時候，也可以單獨升級和重啟 Agent，而不用重啟 Mysql 進程，可以做到無損升級。

如果 Master 節點發生故障，它的 Agent 會上報它的異常給 MetaServer。接著 Master 會降級成為 Slave。再從剩下的 Slave 中選舉一個出來作為 Master。后面的請求就會發送給新的 Master。整個容災切換機制都無需人為干預，通過這種方式實現高可用。

圖片

以上就是 TDSQL 的強一致性、無損升級、高可用在架構上實現的原理。

另外還有一個我覺得在 TDSQL 中比較值得學習的一個點是它的扁鵲智能化 DBA 平臺。我們大家在做自己的系統時也可以借鑒這個思路實現自己系統的高效運維。

當集群規模大了之后，必然會出現各種各樣的問題。比如網絡異常發生、SSD 衰老，如果這些問題全部依賴人工去排查和處理，效率太低了。而且未來分布式系統的規模會越來越大，所以人工維護必然需要被代替。以下是 TDSQL 的扁鵲平臺架構。

圖片

DBA 靠這個平臺可以發現各種集群中運行的問題。比如差 SQL、擴容異常、鎖分析等等各種日常運維工作。更高效率的運維也是實現高可用的另一個關鍵要素。

最后，再次恭喜 TDSQL 登錄中國分布式關系型數據庫“領導者”類別，這份來自業界的高度評價十分難得。相信國產數據庫未來一定會越來越強！