介紹

TiDB 是 PingCAP 公司自主設計、研發的開源分布式關系型數據庫，是一款同時支持在線事務處理與在線分析處理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式數據庫產品，具備水平擴容或者縮容、金融級高可用、實時 HTAP、云原生的分布式數據庫、兼容 MySQL 5.7 協議和 MySQL 生態等重要特性。目標是為用戶提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解決方案。TiDB 適合高可用、強一致要求較高、數據規模較大等各種應用場景。

特點

• 一鍵水平擴容或者縮容：得益于 TiDB 存儲計算分離的架構的設計，可按需對計算、存儲分別進行在線擴容或者縮容，擴容或者縮容過程中對應用運維人員透明。
• 金融級高可用：數據采用多副本存儲，數據副本通過 Multi-Raft 協議同步事務日志，多數派寫入成功事務才能提交，確保數據強一致性且少數副本發生故障時不影響數據的可用性。可按需配置副本地理位置、副本數量等策略滿足不同容災級別的要求。
• 實時 HTAP：提供行存儲引擎 TiKV、列存儲引擎 TiFlash 兩款存儲引擎，TiFlash 通過 Multi-Raft Learner 協議實時從 TiKV 復制數據，確保行存儲引擎 TiKV 和列存儲引擎 TiFlash 之間的數據強一致。TiKV、TiFlash 可按需部署在不同的機器，解決 HTAP 資源隔離的問題。
• 云原生的分布式數據庫：專為云而設計的分布式數據庫，通過 TiDB Operator 可在公有云、私有云、混合云中實現部署工具化、自動化。
• 兼容 MySQL 5.7 協議和 MySQL 生態：兼容 MySQL 5.7 協議、MySQL 常用的功能、MySQL 生態，應用無需或者修改少量代碼即可從 MySQL 遷移到 TiDB。提供豐富的數據遷移工具幫助應用便捷完成數據遷移。

與傳統的單機數據庫相比，TiDB 具有以下優勢：

• 純分布式架構，擁有良好的擴展性，支持彈性的擴縮容。
• 支持 SQL，對外暴露 MySQL 的網絡協議，并兼容大多數 MySQL 的語法，在大多數場景下可以直接替換 MySQL。
• 默認支持高可用，在少數副本失效的情況下，數據庫本身能夠自動進行數據修復和故障轉移，對業務透明。
• 支持 ACID 事務，對于一些有強一致需求的場景友好，例如：銀行轉賬。
• 具有豐富的工具鏈生態，覆蓋數據遷移、同步、備份等多種場景。

場景

• 對數據一致性及高可靠、系統高可用、可擴展性、容災要求較高的金融行業屬性的場景

眾所周知，金融行業對數據一致性及高可靠、系統高可用、可擴展性、容災要求較高。傳統的解決方案是同城兩個機房提供服務、異地一個機房提供數據容災能力但不提供服務，此解決方案存在以下缺點：資源利用率低、維護成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 無法真實達到企業所期望的值。TiDB 采用多副本 + Multi-Raft 協議的方式將數據調度到不同的機房、機架、機器，當部分機器出現故障時系統可自動進行切換，確保系統的 RTO <= 30s 及 RPO = 0。

• 對存儲容量、可擴展性、并發要求較高的海量數據及高并發的 OLTP 場景

隨著業務的高速發展，數據呈現爆炸性的增長，傳統的單機數據庫無法滿足因數據爆炸性的增長對數據庫的容量要求，可行方案是采用分庫分表的中間件產品或者 NewSQL 數據庫替代、采用高端的存儲設備等，其中性價比最大的是 NewSQL 數據庫，例如：TiDB。TiDB 采用計算、存儲分離的架構，可對計算、存儲分別進行擴容和縮容，計算最大支持 512 節點，每個節點最大支持 1000 并發，集群容量最大支持 PB 級別。

• Real-time HTAP 場景

隨著 5G、物聯網、人工智能的高速發展，企業所生產的數據會越來越多，其規模可能達到數百 TB 甚至 PB 級別，傳統的解決方案是通過 OLTP 型數據庫處理在線聯機交易業務，通過 ETL 工具將數據同步到 OLAP 型數據庫進行數據分析，這種處理方案存在存儲成本高、實時性差等多方面的問題。TiDB 在 4.0 版本中引入列存儲引擎 TiFlash 結合行存儲引擎 TiKV 構建真正的 HTAP 數據庫，在增加少量存儲成本的情況下，可以同一個系統中做聯機交易處理、實時數據分析，極大地節省企業的成本。

• 數據匯聚、二次加工處理的場景

當前絕大部分企業的業務數據都分散在不同的系統中，沒有一個統一的匯總，隨著業務的發展，企業的決策層需要了解整個公司的業務狀況以便及時做出決策，故需要將分散在各個系統的數據匯聚在同一個系統并進行二次加工處理生成 T+0 或 T+1 的報表。傳統常見的解決方案是采用 ETL + Hadoop 來完成，但 Hadoop 體系太復雜，運維、存儲成本太高無法滿足用戶的需求。與 Hadoop 相比，TiDB 就簡單得多，業務通過 ETL 工具或者 TiDB 的同步工具將數據同步到 TiDB，在 TiDB 中可通過 SQL 直接生成報表。

架構

在內核設計上，TiDB 分布式數據庫將整體架構拆分成了多個模塊，各模塊之間互相通信，組成完整的 TiDB 系統。對應的架構圖如下：

• TiDB Server：SQL 層，對外暴露 MySQL 協議的連接 endpoint，負責接受客戶端的連接，執行 SQL 解析和優化，最終生成分布式執行計劃。TiDB 層本身是無狀態的，實踐中可以啟動多個 TiDB 實例，通過負載均衡組件（如 LVS、HAProxy 或 F5）對外提供統一的接入地址，客戶端的連接可以均勻地分攤在多個 TiDB 實例上以達到負載均衡的效果。TiDB Server 本身并不存儲數據，只是解析 SQL，將實際的數據讀取請求轉發給底層的存儲節點 TiKV（或 TiFlash）。
• PD (Placement Driver) Server：整個 TiDB 集群的元信息管理模塊，負責存儲每個 TiKV 節點實時的數據分布情況和集群的整體拓撲結構，提供 TiDB Dashboard 管控界面，并為分布式事務分配事務 ID。PD 不僅存儲元信息，同時還會根據 TiKV 節點實時上報的數據分布狀態，下發數據調度命令給具體的 TiKV 節點，可以說是整個集群的“大腦”。此外，PD 本身也是由至少 3 個節點構成，擁有高可用的能力。建議部署奇數個 PD 節點。
• TiKV Server：負責存儲數據，從外部看 TiKV 是一個分布式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region，每個 Region 負責存儲一個 Key Range（從 StartKey 到 EndKey 的左閉右開區間）的數據，每個 TiKV 節點會負責多個 Region。TiKV 的 API 在 KV 鍵值對層面提供對分布式事務的原生支持，默認提供了 SI (Snapshot Isolation) 的隔離級別，這也是 TiDB 在 SQL 層面支持分布式事務的核心。TiDB 的 SQL 層做完 SQL 解析后，會將 SQL 的執行計劃轉換為對 TiKV API 的實際調用。所以，數據都存儲在 TiKV 中。另外，TiKV 中的數據都會自動維護多副本（默認為三副本），天然支持高可用和自動故障轉移。
• TiFlash：TiFlash 是一類特殊的存儲節點。和普通 TiKV 節點不一樣的是，在 TiFlash 內部，數據是以列式的形式進行存儲，主要的功能是為分析型的場景加速。

存儲

TiKV 沒有選擇直接向磁盤上寫數據，而是把數據保存在 RocksDB 中，具體的數據落地由 RocksDB 負責。這個選擇的原因是開發一個單機存儲引擎工作量很大，特別是要做一個高性能的單機引擎，需要做各種細致的優化，而 RocksDB 是由 Facebook 開源的一個非常優秀的單機 KV 存儲引擎，可以滿足 TiKV 對單機引擎的各種要求。這里可以簡單的認為 RocksDB 是一個單機的持久化 Key-Value Map。

TiKV 利用 Raft 來做數據復制，每個數據變更都會落地為一條 Raft 日志，通過 Raft 的日志復制功能，將數據安全可靠地同步到復制組的每一個節點中。不過在實際寫入中，根據 Raft 的協議，只需要同步復制到多數節點，即可安全地認為數據寫入成功。

總結一下，通過單機的 RocksDB，TiKV 可以將數據快速地存儲在磁盤上；通過 Raft，將數據復制到多臺機器上，以防單機失效。數據的寫入是通過 Raft 這一層的接口寫入，而不是直接寫 RocksDB。通過實現 Raft，TiKV 變成了一個分布式的 Key-Value 存儲，少數幾臺機器宕機也能通過原生的 Raft 協議自動把副本補全，可以做到對業務無感知。

事務

TiDB 支持分布式事務，提供樂觀事務與悲觀事務兩種事務模式。TiDB 3.0.8 及以后版本，TiDB 默認采用悲觀事務模式。TiDB 可以顯式地使用事務（通過 [BEGIN|START TRANSACTION]/COMMIT 語句定義事務的開始和結束）或者隱式地使用事務 (SET autocommit = 1)。TiDB 支持語句執行失敗后的原子性回滾。如果語句報錯，則所做的修改將不會生效。該事務將保持打開狀態，并且在發出 COMMIT 或 ROLLBACK 語句之前可以進行其他修改。由于底層存儲引擎的限制，TiDB 要求單行不超過 6 MB。可以將一行的所有列根據類型轉換為字節數并加和來估算單行大小。

TiDB 同時支持樂觀事務與悲觀事務，其中樂觀事務是悲觀事務的基礎。由于樂觀事務是先將修改緩存在私有內存中，因此，TiDB 對于單個事務的容量做了限制。

TiDB 中，單個事務的總大小默認不超過 100 MB，這個默認值可以通過配置文件中的配置項 txn-total-size-limit 進行修改，最大支持 10 GB。單個事務的實際大小限制還取決于服務器剩余可用內存的大小，執行事務時 TiDB 進程的內存消耗相對于事務大小會存在一定程度的放大，最大可能達到提交事務大小的 6 倍以上。

在 4.0 以前的版本，TiDB 限制了單個事務的鍵值對的總數量不超過 30 萬條，從 4.0 版本起 TiDB 取消了這項限制。

 兼容性

TiDB 高度兼容 MySQL 5.7 協議、MySQL 5.7 常用的功能及語法。MySQL 5.7 生態中的系統工具 (PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper/Myloader)、客戶端等均適用于 TiDB。但 TiDB 尚未支持一些 MySQL 功能，可能的原因如下：

• 有更好的解決方案，例如 JSON 取代 XML 函數。
• 目前對這些功能的需求度不高，例如存儲流程和函數。
• 一些功能在分布式系統上的實現難度較大。

除此以外，TiDB 不支持 MySQL 復制協議，但提供了專用工具用于與 MySQL 復制數據。

• 從 MySQL 復制：TiDB Data Migration (DM) 是將 MySQL/MariaDB 數據遷移到 TiDB 的工具，可用于增量數據的復制。
• 向 MySQL 復制：TiCDC 是一款通過拉取 TiKV 變更日志實現的 TiDB 增量數據同步工具，可通過 MySQL sink 將 TiDB 增量數據復制到 MySQL。