9月16日，Distributed Cloud|2021全球分布式雲大會·上海站隆重召開。在全球分布式雲大會不懈布道下，雲計算行業對分布式雲的關注度愈發高漲，以全球分布式雲聯盟成員為代表，湧現出了大量分布式雲技術和實踐成果，為分布式雲計算發展夯實了基礎。
2021全球分布式雲大會為分布式雲計算發展再添強大推力，本次大會共設有分布式雲主題報告會、邊緣雲論壇、雲原生專題論壇、分布式資料庫論壇四大論壇，圍繞分布式雲、邊緣算力、雲原生、分布式架構等技術與實踐展開。全球分布式雲聯盟聯合阿裡雲、騰訊雲、Google Cloud、中興通訊、京東雲、安邁雲、網心科技等國内外分布式雲頂尖技術服務商，共話分布式雲創新新趨勢，共謀雲計算變革新未來，共享分布式雲計算新紅利！
在9月16日下午召開的雲原生專題論壇上，騰訊雲資料庫專家工程師張遠發表了題為《騰訊雲TDSQL-C雲原生資料庫技術》的精彩演講。
TDSQL-C簡介
張遠介紹說，TDSQL-C是騰訊雲自研的新一代企業級雲原生分布式資料庫，經過五年的打磨，具有以下幾個關鍵的特性：
可靠性。TDSQL-C基于共享存儲的雲原生架構，存儲是多副本的，能夠保證資料可靠性。同時能夠做到即時復原，任意時間資料都可靠。
極緻性能。騰訊雲對主備機讀寫性能做了全面優化，同時也根據不同規格做針對性優化。
可用性。TDSQL-C可以做到秒級的RTO，故障幾乎無感覺，同時主備延遲可以做到毫秒級。此外，基于共享記憶體，資料能夠快速恢複、快速預熱。
彈性擴充。資料能夠快速透明拓展，而且容量最大可以達到1PB，滿足大的需求。
在總體架構上，TDSQL-C是基于共享存儲的存儲和計算分離的架構。與傳統的MySQL主備架構對比，可以看到傳統的MySQL主備通過binlog進行邏輯複制，而TDSQL-C是通過redo日志進行的實體複制；傳統的MySQL需要向存儲寫多份資料包括data，binlog，redo log等， 而TDSQL-C隻需向存儲寫一份redo日志即可；傳統的MySQL主備各存儲一份資料，而TDSQL-C基于共享存儲隻有一份資料。
TDSQL-C核心關鍵技術
張遠演講的第二部分會圍繞關鍵特性展開，詳細介紹了TDSQL-C特性背後的技術原理和細節。
TDSQL-C之高性能。
TDSQL-C 高性能-plan cache
TDSQL-C 高性能的一個重要優化是實作了查詢計劃緩存，稱之為plan cache。
圖中展示了一條SQL在資料庫中的執行過程，會經過以下幾個階段：
首先MySQL server接受到使用者的SQL請求，在parse階段解析為邏輯的執行計劃樹；接下來在查詢優化階段生成實體的查詢計劃；然後執行器從存儲引擎擷取資料進行計算。
經過plan cache優化後，一條SQL執行過程省略了前面的解析和查詢優化階段，SQL的執行時間大大縮短了。
優化效果以sysbench場景為例，不同顔色代表不同階段的耗時，可以看到經過plan cache優化後，parse和查詢優化時間減少了，性能提升了70%左右。
TDSQL-C高性能-異步組送出
TDSQL-C是計算和存儲分離的架構，是以計算節點和存儲節點之間的網絡IO存在一定時延。而寫事務送出時需要保證redo先刷盤才能完成送出，是以Redo日志刷盤存在網絡IO。TDSQL-C線上程池的基礎上進行了異步組送出優化，事務送出交給背景線程異步完成，将線程池資源提前釋放進而能夠去處理更多的請求。優化後整體的讀寫事務QPS有70%的提升。
TDSQL-C 高性能-Log Compaction
TDSQL-C是基于日志的資料庫，計算機節點和存儲節點之間有日志的傳輸，同時Master節點和TXStore存儲之間也有redo日志傳輸，TDSQL-C将redo日志進行了壓縮。
下圖是redo日志的結構，一條普通的redo日志包括日志頭和日志内容，日志頭主要包括日志類型以及Space ID和pageno等資訊。通常情況下日志頭占了日志的較大一部分。TDSQL-C對redo日志進行壓縮存儲，對于同一頁面進行修改的多條redo日志可以共享一個日志頭。優化後redo日志量減少了30%。
TDSQL-C之高可用
TDSQL-C 高可用-實體複制
傳統的MySQL的是通過binlog進行複制的。Binlog複制是在MySQL server層進行的，binlog記錄的是邏輯的修改記錄，binlog在備庫apply需要經過server層的parser,optimizer後再經過engine的btree查找才能修改到對應的記錄。這個路徑比較長，複制速度慢。
而騰訊雲TDSQL-C采用的是redo實體複制。Redo日志記錄的是頁面實體修改記錄，redo複制是在engine層進行的，備庫apply redo日志不需要查找就可以直接定位到頁面，在記憶體中完成頁面的修改。是以複制速度快。
更重要的一點是，TDSQL-C是基于共享存儲的，主備資料實體上是一緻的，而binlog複制隻能保證邏輯一緻。
TDSQL-C 高可用-備庫延遲優化
TDSQL-C高可用另一個優化是備庫延遲優化，TDSQL-C最多支援16個備庫提供讀服務，備庫延遲可以達到毫秒級别。其中一個優化就是備庫讀寫IO沖突優化。TDSQL-C備庫是提供讀服務的，同時備庫也會apply主庫傳來的redo日志。
張遠以場景舉例說，首先使用者讀取pageA，pageA不在buffer pool中，那麼會從TXStore中請求pageA，TXStore中請求pageA就存在網絡和IO的開銷。同時redo日志回放線程上有log1/log2/log3正在等待回放到pageA上。也就是說，使用者發起的讀操作可能阻塞redo日志回放線程，進而導緻主備延遲。
優化方案是将pageA上的redo日志緩存到page上的連結清單中，pageA IO完成以後再将連結清單中的redo日志回放到pageA上。這樣pageA的IO過程就不阻塞redo的回放了。
TDSQL-C 高可用-獨立buffer pool
TDSQL-C 高可用的另一個優化是獨立buffer pool。Buffer pool是InnoDB資料頁的緩存。
計算節點HA重新開機後，buffer pool需要重新加載進行預熱，持續時間比較長，期間業務會受到較大影響。
TDSQL-C 将buffer pool從計算節點獨立出來放到共享記憶體中，計算節點crash後buffer pool可以獨立存在。這樣一來，Buffer pool 不需要預熱，重新開機時間也縮短了。
TDSQL-C 高可用-秒級RTO
TDSQL-C在基于redo日志的架構下，計算節點crash recovery不需要apply redo，redo的apply由存儲節點來完成。進而crash recovery時間相比傳統MySQL要快很多。在此基礎上，TDSQL-C做了更多的優化，可以做到秒級RTO。例如經過測試，大規格執行個體重新開機速度比較慢，例如buffer pool為500G的大執行個體重新開機，初始化buffer pool耗時23秒，這對于使用者來說是不可接受的。優化方案是并行初始化加pag上的mutex延遲初始化。并行初始化是指按InnoDB buffer pool instance來并行初始化。而page mutex延遲初始化，是指當page首次使用時才初始化，而不是在啟動時全部都初始化。優化後buffer pool初始化速度提升近20倍，而且騰訊雲将這個方案也貢獻給了MySQL官方。另外復原段并行初始化也貢獻給了MySQL官方。
TDSQL-C 之彈性擴充
TDSQL-C 備庫可以提供讀服務。為了提供更好的讀服務，騰訊雲做了許多讀優化。Btree一緻性讀優化就是其中一個。
Btree在資料的更新過程中會發生SMO操作，即btree的分裂或合并。
如圖所示，Btree發現分裂，page B分裂為pageB和pageC。Btree分裂時，使用者查詢pageB可能導緻資料不一緻甚至crash。但主庫在Btree發生分裂時會通過index鎖和page lock的方式保證正在發生分裂的page不被其他使用者通路。但對于備庫來說，備庫通過redo日志不能感覺Btree的SMO操作，SMO操作所産生的日志隻有頁面修改的資訊，redo日志中沒有index lock上鎖資訊。是以備庫在SMO過程是沒有被保護的，備庫的查詢可能異常。
這裡有一個可選方案就是将SMO操作index lock記錄到日志中，備庫解析index lock日志對整個btree加index lock。但index lock會鎖整個btree導緻并發查詢性能比較差。
TDSQL-C對此進行了優化，MySQL的SMO操作是原子的，所有産生的redo日志都在一個mini-transaction中。引入新的日志類型來标記redo日志中SMO操作的邊界。這樣使用者在查詢btree過程遇到page在SMO操作重新掃描btree即可。例如使用者通路page A時會判斷一下page是否在SMO，如果A在在mtr start和end之間則重試。
這樣優化後，備庫讀不會被主庫更新産生的SMO操作所阻塞。
TDSQL-C 其它特性
TDSQL-C 秒改列（instant modify column）
在官方MySQL8.0支援instant add column後，修改列類型操作便順勢成為MySQL中最不友好的DDL類型，修改列類型既不是inplace的同時也需要rebuild table。而在我們使用者實踐中，修改列類型也是使用者執行比較頻繁的DDL之一，而此操作會長時間阻塞使用者的讀寫請求，對業務的影響非常大。
TDSQL-C創新的支援了instant modify column功能，達到了秒級修改列的效果。
具體的實作方式是：
中繼資料多版本化, 表中繼資料儲存列的多個版本資訊，使用者隻能看到的總是最新的表中繼資料。
行記錄增加版本資訊對應到不同版本的表中繼資料上。
修改列隻修改中繼資料，修改列的過程中不修改實際的行記錄。
行記錄讀取時，老版本記錄會自動轉換為最新版本的記錄。
行記錄更新時，老版本記錄會自動更新為最新版本的記錄。
值得注意的是，這是業界首創的方案。
TDSQL-C purge預讀
Undo 空間膨脹問題是MySQL曆史老大難問題，TDSQL-C創新的通過purge預讀解決了此問題。
Purge會讀取undo page并清理delete mark的記錄，清理完成後會釋放undo page，進而最終釋放undo表空間。
IO bound場景， purge時讀取undo page更容易出現remote IO。而remote IO時占用時間比較長，導緻purge不及時undo日志空間膨脹。
解決方法是實作purge預讀機制：根據事務送出順序在記憶體中儲存undo page的purge順序用于預讀。Purge coordinator異步預讀這些page。
TDSQL-C展望
展望TDSQL-C的未來發展，張遠表示，未來TDSQL-C會進一步加強查詢優化的能力，比如增加新的join類型如SMJ， 以及在parallel query上做一些拓展。同時TDSQL在支援多寫方面會進一步探索，未來TDSQL-C也會向HTAP方向演進，TDSQL-C會同時具備OLTP和OLAP的能力。