TDSQL 是騰訊雲旗下金融級分布式資料庫産品，具備強一緻高可用、全球部署架構、分布式水準擴充、高性能、 HTAP 雙引擎、Oracle 相容、企業級安全、便捷易運維等特性，目前金融核心系統客戶已超過 20 家，尤其 在銀行傳統核心系統領域，位居國内第一陣營。客戶涵蓋多家國有大行，及平安銀行、張家港銀行、昆山農 商行等頭部銀行及廣泛金融行業機構。
TDSQL 架構介紹
TDSQL 的全稱為 Tencent Database SQL。下圖是 TDSQL 的最新技術架構，它描繪了一個計算/存儲分離、 資料面 / 管控面分離的高可用的原生分布式架構的關系型資料庫。 TDSQL 分為三層：綠色部分是計算層，稱之為 SQLEngine ；紫色部分是管控層，簡稱為 MC ，負責整個 叢集的管控排程工作；藍色部分是存儲層，稱為 TDStore 。 TDSQL 架構三個重要的特性：全分布式，無論在計算層還是管控層，每一層都是分布式的架構；計算與存 儲分離；可實作動态可擴充功能特性。
TDSQL 的四個主要功能特點分别是：
- 高度相容 MySQL 。 TDSQL 對單機遷移過來的業務，相容度高達 100%，能夠實作無感覺遷移。
- 高可擴充性。在存儲層和計算層，使用者隻需手動在管理界面上添加一個存儲節點或計算節點，後續内部的 管控機制會自洽地完成整個流程。
- 支援原生 Online DDL，可多寫架構下以原生方式實作 Online DDL。
- 全局讀一緻性。TDMetaCluster 統一配置設定全局唯一遞增事務時間戳，實作金融級場景下的資料強一緻。
分布式架構主要分為計算層、存儲層和管控層。
首先是計算層。TDSQL 計算層最大的特點是多主架構，每個節點都支援讀寫，完全互相獨立；每個計算節 點為無狀态，具備擴容優勢，可實作 MySQL 的高度相容，具備無狀态化的彈性擴容的架構特性。
其次是存儲層。它是我們自研的 KV 存儲引擎。在存儲層和計算層的互動中，存儲層承擔事務協調者的角色。 我們以一定方式将資料打散到每個存儲節點上，每個資料分片稱為 Region 。存儲層對所有資料的狀态自身 無感覺，隻負責資料的讀寫，所有資料的排程都由它與 MC 的互動來進行。
最後是管控層。它是一個分布式的叢集，以 N 倍的方式去部署。在整個叢集中，它要同時承擔管控層面和數 據層面的工作。比如在資料層面，MC 負責一個全局、一個中心的嚴格遞增，是唯一的配置設定者角色，且同時 負責管理所有的計算節點、存儲節點的中繼資料、MDL 鎖。
以下是資料庫中常見的主功能流程：
分布式事務。資料庫的通路是天然的分布式事務。整體流程為：從 MySQL 用戶端發送請求，通過計算層對 存儲層進行讀寫，讀寫過程中，存儲層和計算層都會去和 MC 互動，擷取時間戳，最終确定每個事務之間的 偏序關系，完成整個流程。
無感覺擴縮容。當存儲空間不夠時就需要擴容。在擴容過程中，必然會涉及到資料的搬遷。如下圖例子所示， 整個叢集中隻有一個存儲節點，當需要擴容時，可以在界面上點選多購買一個存儲節點。此時存儲節點上數 據的分裂搬遷、計算層對最終資料路由的感覺、計算層感覺路由的變化後完成的重試等過程可以完全自洽地 包含在整個資料庫體系中，實作業務層無感覺。
Online DDL。TDSQL 的分布式體系架構采用多寫架構。為達到更好的并發性能，需要在多寫的架構下，實 現 Online DDL。相較同類産品，當業務嘗試在運作過程中加一列、加一個索引時，需要借助外部的工具， 及堵塞業務來完成 DDL 的操作。為了更好的使用者體驗，降低對業務的影響，通過 TDSQL 可以把多寫架構 下的 DDL 以原生方式去完成。
TDSQL 在分布式場景下的挑戰
TDSQL 架構的三大功能特性：
- 原生分布式，全部都是分布式，沒有中心節點管控。
- 存算分離，計算跟存儲完全分離，不在一個伺服器上。
- 資料跟管控完全分離，資料層面完全不參與資料管理。
這些特性直接、簡單， 卻在工程落地時遇到 諸多挑戰，主要是高 性能、高可用、複雜 排程三個方面。下面 将着重分享我們在高 性能、複雜排程方面 遇到的挑戰。
首先是高性能方面 的挑戰。在架構上， 要做到分布式的完 全存算分離的架構， MC 作 為 集 群 内 唯 一一個中心的管控 子產品，必須承擔全 局授時源角色。
在分布式事務的整體架構圖中，可以了解到 MC 在事務過程中需要和存儲層做網絡互動，提供時間戳，這是 關鍵路徑。同時 TDSQL 的計算層和存儲層都可以靈活擴縮容。存算分離、高擴充的兩個特性也意味着 MC 必須要具有非常高的性能。
在複雜排程層面。我們設計成資料和管控完全分離的架構，資料完全存儲在TDStore上，隻負責資料流的讀寫。 其他工作完全交由管控層去進行，MC 隻需要監控整個叢集的狀态做出關于存儲資源的決策。
TDSQL 在叢集管控的探索與實踐
高性能方面的探索與實踐
在高性能方面，我們采用 非常經典的三段式協程架 構，即一個協程收、處理、 最後再發。這種架構在我們突破 60 萬時就達到性能瓶頸。
通過性能分析，我們意識 到性能瓶頸集中在第二個 協程裡。于是我們将出現 瓶頸的地方并行化。但第 二個協程增加到一定時， 下個瓶頸又出現，因為協 程 1 是單管道模式，新的 瓶頸點集中在協程 1。
我們在下個版本裡做了一個略微複雜的 N 對 N 架構，也是多協程架構。基于此我們發現性能可以提升但 CPU 的消耗非常大。我們的設計目标是 MC 在性能方面有較強的表現，其性能資料能到達 500 萬。但當時 盡管達到 75 核，資料還是停留在 320 萬。我們對此進行 perf 分析，發現問題主要來自 RPC 解析，因為 MC 主要網絡架構的實作是基于 GRPC 的網絡通訊，會有比較大的頭部序列化和反序列化的性能開銷。
已知性能阻礙存在于網絡架構，我們優化的目标就成為擺脫網絡架構帶來的性能限制。對此我們給時間戳的 擷取開發了 TCP ROW Socket 通道。因為時間戳資料結構有一個天然優勢，即請求無狀态、無依賴，隻包 含兩三個整型字段。這時在網絡上發來的任何請求，MC 隻需要收到一個，回答一個，可以去定制化完成請求。
在棄用該架構後，性能提升飛快，在比較低的 CPU 開端的情況下，可以将性能提升到 450 萬。但在後續過 程中，我們發現瓶頸出現在請求進隊列還有請求出隊列的過程中。我們使用 Go Channel 作為消息的進出隊 列載體，Channel 雖然好用且輕量，但底層依舊帶鎖實作，push/pull 操作存在着百納秒級别的開銷。
對此我們計劃實作無鎖隊列，需要實作單生産者、單消費者模式的場景。基于這種場景，我們實作一個簡單 的信号量，作為兩者之間的喚醒機制。使用該優化方案後，資源的消耗明顯降低且達到更高的性能，峰值吞 吐突破 750 萬。
最初 500 萬的目标雖已完成，但我們團隊仍認為性能資料還可以更好。以下為經典的 CPU 緩存的 MESI 狀 态轉換圖。一行 CPU 的 Cache Line 可以容納 64 個位元組，在我們的資料結構中，将其中多個 8 位元組的變 量放在同一個緩存，如果一個更新非常多，另一個更新的少，就會影響另一個原子變量的讀寫。從圖檔右邊 可知，在這裡把變量的 8 位元組對齊後，就解決 CPU 緩存行的問題，性能資料也從 750 萬上升至 920 萬。 此時我們的目标是實作單中心的千萬級别的性能資料。
為了進一步實作單中心的千萬級别的性能資料，我們從業務場景進一步深挖。在整個叢集中，MC 在時間戳 方面是單一的提供者，而叢集中衆多的計算節點和存儲節點會産生源源不斷的請求，是以在分析生産者和消 費者速度時，我們發現生産者速度遠遠跟不上消費者速度。為此我們進行了簡單的改造，即來一批請求再消 費一批時間戳，以批量請求方式去喚醒消費者。為了适應業務場景，我們還對該優化做了開關，運維人員可 以根據業務場景的需求進行調節。執行批量化操作後，整體峰值已經提升至兩千萬，許多資料庫執行個體的業務 場景都無法到達這種高壓力。
下圖為 TDSQL 原生資料庫下，我們通過一系列優化手段達到 2000 萬性能資料的過程。
複雜排程方面的探索與實踐
由于實作資料面與管控面的分離，MC 要負責整個叢集所有跟資源相關的管控。如圖所示，圖中畫有 MC 的 主要功能。
MC 需要負責時間戳的提供，管理全局的唯一 ID 的配置設定、DDL 的協調、計算層管控層資源的中繼資料以及數 據分片的管理。在管控層的不同層面，所有跟管理排程相關的工作都集中在 MC 。
為了實作複雜排程，我們首先劃分資源層級，制定可用的具有可擴充性的基礎架構，将 MC 子產品從管理任務 中釋放。将每個資源層級必須劃厘清楚，使得資料路徑上的所有子產品隻需要被動執行，不需要更新狀态。我 們從叢集層面、複制組層面和副本層面進行劃分，劃分出許多子狀态及子步驟。
比如在擴容過程中，有一個資料分片，副本分布在 123 三個存儲節點中，如果要進行資料遷移使得一主兩備 變為 1234 分布，任意時刻這四個節點都知道自己要做的原子子步驟，整個遷移過程實作零感覺。
遷移過程包含五個原子子步驟：先在節點 4 上建立新部分，再将新部分加入到原本的資料複制同步組中，去 掉的副本的狀态設定為 off line，最後再把該副本删除。在分布式資料庫中随時可能有節點挂掉，但通過步 驟劃分，無論是 MC 挂掉還是 TDStore 挂掉，節點拉起來後都知道要如何操作。通過這樣的機制，存儲層 對每個任務的推進或復原完全無感覺，全部由 MC 來做協調。
該機制主要有以下三方面的效果：
首先是性能。該機制對性能提升的促進非常顯著，在叢集比較大時可以輕松支援 EB 級存儲。比如在 500 萬 資料分片的量級下，MC 用 20 個核就能完全支援。通過資料狀态與排程狀态的分離，大大降低了 MC 負載。 性能上的收益還展現在存儲層上。在任意時刻它隻需要接收到一個原子步驟即可。是以在代碼層面，存儲層 不需要任何關注資料資源狀态的代碼，更有利于進行性能優化。
其次是健壯性。每個任務都是有限的狀态機，任意一個參與者，如管控或存儲，出現互動中斷，都能夠以确 定方式進行任務的復原或恢複。
最後是可擴充性。每個管控任務分為多個原子步驟進行，有利于以插件式方式去定義其他更多更複雜的任務。 整個過程中隻需要将原子步驟拼裝組合，MC 就可以實作複雜排程。
資料分布方面的探索與實踐
原始版本中，MC 對資料分布管理隻有實體位置概念，基于擴充引擎和分布式協定打造的 KV 存儲引擎，數 據分片在整個分布式存儲叢集中按照主鍵從空到正無窮的字元序來進行分布。比如建立表或二級索引時，如 果要表達成 KV 形式，主鍵和二級索引都有對應的 ID 。存儲層中以 Key 區間代表一個資料分片，如 01-02 資料分片，落在存儲節點 1 上，02-03 資料分片，落到存儲節點 2 上。這種情況下，同一張表的資料的主 鍵和二級索引會落在不同的 TDStore 上，這就會造成很大的負面影響。
舉個例子，有一張表，每天有大量不同的流水寫入，有三億行資料，業務為友善查詢，做了 20 個索引。在 最壞的情況下，20 個索引分别落在不同的 Region ，又落在了不同的 TDStore 。資料庫使用者從操作上更 新了一行，但可能會發展成 20 個涉及到 60 個參與者的分布式事務，帶來 60 次同步的性能損耗。在這種情 況下，我們針對經常出現的業務場景對兩階段送出進行優化，讓更多的送出變成一階段送出。
我們設立表内資料的概念，每個資料在實體層面都可以知道每個 Key 落在哪個 TDStore，但無法感覺到它 們屬于哪個二級索引。對此我們需要建立關系去建立表，使得在建立表和索引時，MC 可以感覺到每個 Key 在實體意義上屬于哪個 TDStore ，邏輯意義上屬于哪些表的分區、屬于哪些表的二級索引。
我們還引入了複制組的概念。在原始版本中，每個資料分片是一個複制組，現在則是将多個 Region 歸屬于 一個複制組，通過管控體系架構的改變，将表資料和二級索引放在同一複制組裡。這種做法的好處有兩方面： 一方面，業務中常常按照分區鍵來劃分事務，一次性修改的資料非常大，可能隻落在同一複制組裡，這時需 要進行多次網絡互動才能完成一個分布式事務，優化後隻需要一次落盤即可完成；另一方面的好處是計算下推，由于計算層可以感覺到要寫的主鍵、二級索引都在同一 TDStore 的同一複制組内，就可以提前将邏輯 下推到存儲層中完成。
接下來解決的問題是表與表之間的親和性。在部分系統中，以一定規則如哈希去分區的表結構中，在更新表 1 分區時，也會去通路表 2 的 1 分區。這就要求管控層必須了解表與表之間的概念。如果能感覺到它們是在 同一組事務裡被操作的機關，就可以更好地改善事務的兩階段送出。
對此我們提供了一個擴充文法。假如使用者有需求，可以去指定他所傾向的資料分布政策，為該政策命名，允 許在該分布政策裡再指定分區政策。如下圖所示，當下面第三行建立表時，如果有兩個表在業務場景中經常 被通路，就可以将它們關聯到同一 DP 組裡，MC 會在背景建立表。所有的分布政策都會通過 MC 進行， MC 可以在背景将這些關聯的表做背後的排程優化。這就為更多跨表之間的操作提供較多的可能性。
Risk & Opportunity
未來我們仍有許多挑戰需要克服。首先是全局事務時間戳，目前 MC 承擔許多的管控操作，後續我們計劃 将其設計成多程序模式，全局事務時間戳獨占一個程序。其次是 Lieutenant 分流，我們計劃增加副隊長角色， 分流部分網絡。最後是資料親和排程的利用也是我們未來會去重點攻堅的領域。
出處：InfoQ 騰訊雲技術實踐精選集2021