TiDB 是 PingCAP 公司研發的開源分佈式關係型數據庫，結合了傳統的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，具備「分佈式強一致性事務、在線彈性水平擴展、故障自恢復的高可用、跨數據中心多活」等核心特性，是大數據時代理想的數據庫集羣和雲數據庫解決方案。
UCloud 於今年 8 月 將 TiDB 公有云化並推出 UCloud TiDB Service，當前使用的 TiDB 版本爲 3.0.5 。UCloud TiDB Service 相比裸機部署性能並無損耗，提供跨可用區高可用，對監控和 Binlog 等做了改造增強，使用戶可獲得一鍵創建、按需付費、靈活擴縮容的 TiDB 服務。
UCloud TiDB Service
爲什麼叫 UCloud TiDB Service？這裏強調 Service 是因爲從公有云用戶的角度來看，TiDB 運行在公有云平臺上，其實是以服務的形式呈現而不是一個物理資源。UCloud TiDB Service 是一個支持原生 MySQL 協議的，高性能、跨可用區高可用、高可擴展的，面向 Serverless 的分佈式數據庫服務。
兼容原生 MySQL 協議
大多數情況下，無需修改代碼即可從 MySQL 輕鬆遷移至 TiDB，分庫分表後的 MySQL 集羣亦可通過 TiDB 工具進行實時遷移。
跨可用區高可用
TiDB 本身雖具備一定高可用性，但一般用戶沒有跨可用區部署條件。UCloud TiDB Service 的所有組件都是跨可用區部署。TiDB 所有模塊的多實例部署能力，結合 UCloud 跨可用區部署能力，UCloud TiDB Service 可抵禦可用區級故障。
動態擴展
TiDB 無論是計算節點還是存儲節點都可以實現水平擴展，通過簡單地增加新節點即可按需擴展吞吐或存儲，輕鬆應對高併發、海量數據場景。
Serverless
Serverless 的產品形態讓用戶更加簡單快捷的使用到 TiDB，無需關心底層的物理資源，也無需關心底層分佈部署的細節。
按需付費，接入成本低
無需指定 CPU、內存、硬盤等資源，用戶只需按實際使用的硬盤和存儲量進行付費，節省了前期的硬件成本投入。
性能對比
我們做了一個測試，在相同物理配置（Intel Xeon E5-2620 v4, DDR4_16GB_2400MHz x12, U.2_NVMe_3.2TB x2 ）和相同軟件部署（TiDB x3, TiKV x3, PD x3 ）情況下，測試條件爲 sysbench 512 threads, 32 tables, 1000 萬行。在裸機上部署 TiDB 和 UCloud TiDB Service 的性能對比如下表所示：
結果表明各項指標基本一致，UCloud TiDB Service 和裸機部署相比較，並沒有帶來性能損耗，有些指標表現略好。而在這背後，UCloud 公有云後臺做了哪些事情呢？
打造分佈式數據庫 PaaS 平臺
UCloud 內部做了一個分佈式數據庫的 PaaS 平臺（如上圖），在管理功能上，左邊第一部分有物理機的資源管理，包括每次創建實例的時候資源分配以及實例刪除以後資源回收等等操作。第二部分是集羣部署，一個創建過程先選取合適的物理機，檢測上面的資源是否滿足，滿足以後分配特定的一些資源出來，然後再執行相應的創建工作，這裏面要創建 TiDB 集羣，相應的監控、LB 層，以及部署在公有云上都是運行在用戶 VPC 裏面，需要做 VPC 網絡初使化等工作。第三部分是集羣維護，比如某臺物理機有異常，就要把所有服務遷移到其他的節點面去。這裏面主要涉及的是遷移、擴展、縮容這些工作。
右邊是監控告警，主要用於對一些異常情況的及時通知告警管理；還有運營分析這塊是 UCloud 數據庫運營方面的管理。備份管理負責數據庫的備份與恢復，用戶可以設置比較詳細的備份策略，比如何時備份如何備份等。
原生協議是 MySQL 本來的數據流，在這裏我們加了一層負載均衡，主要有兩個目的：一個是把 IP 地址統一成一個，用戶不需要管理 IP 地址的切換；另外針對公有云服務傳輸做一些控制，主要是帳號和系統方面的控制。
跨可用區部署實現高可用
TiDB 整體是由分佈式 SQL 層（TiDB）、分佈式 KV 存儲引擎（TiKV）以及管理整個集羣的 PD 模塊組成。如圖我們將 TiDB 的 所有組件進行跨可用區部署，並且提供單一高可用接入地址，單一地址的好處是用戶不需要關注多地址，也不需要做地址之間的切換，另外一個好處是整個容災過程對業務完全透明，比如要增加 / 縮掉一個 TiDB 節點，或者要遷移到另外一臺機器時。有了統一地址虛 IP 之後，業務就完全不用考慮地址，所有的操作對用戶完全透明。
對監控的改造
TiDB 本身使用了 Prometheus 作爲監控和性能指標信息收集方案、Grafana 作爲可視化組件進行展示、Alertmanager 用於實現報警機制，但是都是單點部署， 並不具備容災能力。我們將這三個模塊都進行了高可用改造。大家知道，Grafana 本身是沒辦法使用 TiDB 存儲元數據的，我們對 Grafana 源碼進行了修改，改寫了大量 Multi-schema 語句，並且去掉了將字段改小的操作，從而支持了 Grafana 使用 TiDB 存儲元數據。
如圖是一個用戶業務監控系統，左邊有一個 LB，兩個 Grafana 節點，我們通過 LB 連到 Prometheus，從而實現遠程高可用。
對 Binlog 的改造
有這樣一個用戶場景，將 TiDB 數據導入已有的大數據集羣作數據分析， 需要輸出到 Kafka 的日誌格式爲 json， 以便 Flink 消費解析。由於 Binlog 是 PB 格式，目前提供的 driver 只支持 txt, mysql。
經過我們對 Binlogdriver 的改造之後，Binlog 支持輸出 Json 格式、支持將 Json 格式日誌寫入 Kafka。
品質改善和 Bug 修復
在打造 TiDB 服務期間，我們也相繼發現解決了原生 TiDB 的一些小問題，從細節上提升產品品質。其中很多在官方後續的新版本中也已經陸續得到了改善和解決，例如：
Drainer 輸出 db.table 格式的語句 (fixed in 3.0)；
TiDB 升級到 2.1 以後時區變化；
Syncer 在 retry 階段不處理 SIGTERM (fixed)；
Syncer can’t decode set datatype (fixed)；
Drainer 只寫一個 partition 導致數據傾斜，我們可以啓動多個 drainer， 每個 drainer 寫一個 DB；
Raft store 單線程瓶頸 （fixed in 3.0）；
Binlog 開啓 / 關閉 10 分鐘內 DDL 慢 （fixed in 2.1.14）。
還有一些由於跟 MySQL 原生協議不同而導致語句理解上產生的問題，比如 ID 分段自增、GC 時間導致連接中斷、事務條數限制（單條 KV entry 不超過 6MB、總條數不超過 30w、總大小不超過 100MB）、失敗自動重試等。這些問題經過 UCloud 內部的長時間打磨和積累，已經達到了一個相對成熟和穩定的形態。
TiDB 管理模塊
產品控制檯向用戶開放了 TiDB 的管理模塊，分爲四個部分：備份管理、恢復任務、用戶管理、Binlog 同步。具體如下：
備份管理：創建 TiDB 實例時可以選擇是否開啓自動備份策略，備份策略包括備份時間、自動備份保留份數以及自動備份週期。除了自動備份，TiDB 還提供手動備份選擇
恢復任務：TiDB 當前支持從備份文件恢復至一個新的 TiDB 實例，用戶需要提前準備好新實例，恢復工作會覆蓋新實例數據。
用戶管理：TiDB 提供給用戶相應的權限管理，包括新增用戶並初始化權限 、調整用戶權限、刪除非 root 用戶等。
Binlog 同步：可將 TiDB 的增量數據實時同步到其他存儲中，當前支持 MySQL，TiDB 作爲目標存儲。
總結
可以說 TiDB 是爲雲而生的數據庫，UCloud TiDB Service 在保證 TiDB 性能沒有損耗的前提下， 將 TiDB 以服務的形式提供給用戶， 降低了用戶使用門檻， 簡化了用戶管理， 提高了容災能力。未來，UCloud 將繼續與 PingCAP 官方深度合作，致力於爲雲上數據庫創造更多可能性。