當(dāng)我們使用 Mysql數(shù)據(jù)庫(kù)到達(dá)一定量級(jí)以后，性能就會(huì)逐步下降，而解決此類問(wèn)題，常用的手段就是引入數(shù)據(jù)庫(kù)中間件進(jìn)行分庫(kù)分表處理，比如使用 Mycat、ShadingShpere等，但是這種都是過(guò)去式了，現(xiàn)在使用分布式數(shù)據(jù)庫(kù)可以避免分庫(kù)分表
為什么不建議分庫(kù)分表呢？
分庫(kù)分表以后，會(huì)面臨以下問(wèn)題
- 分頁(yè)問(wèn)題，例如：使用傳統(tǒng)寫法，隨著頁(yè)數(shù)過(guò)大性能會(huì)急劇下降
- 分布式事務(wù)問(wèn)題
- 數(shù)據(jù)遷移問(wèn)題，例如：需要把現(xiàn)有數(shù)據(jù)通過(guò)分配算法導(dǎo)入到所有的分庫(kù)中
- 數(shù)據(jù)擴(kuò)容問(wèn)題，分庫(kù)分表的數(shù)據(jù)總有一天也會(huì)到達(dá)極限，需要增大分片
- 開(kāi)發(fā)模式變化，比如在請(qǐng)求數(shù)據(jù)時(shí)，需要帶分片鍵，否則就會(huì)導(dǎo)致所有節(jié)點(diǎn)執(zhí)行
跨庫(kù)跨表查詢問(wèn)題 - 業(yè)務(wù)需要進(jìn)行一定取舍，由于分庫(kù)分表的局限性，有些場(chǎng)景下需要業(yè)務(wù)進(jìn)行取舍
以上只是列舉了一部分問(wèn)題，為了避免這些問(wèn)題，可以使用分布式數(shù)據(jù)庫(kù)TiDB來(lái)處理
TiDB介紹
TiDB 是 PingCAP 公司設(shè)計(jì)的開(kāi)源分布式 HTAP (Hybrid Transactional and Analytical Processing) 數(shù)據(jù)庫(kù)，結(jié)合了傳統(tǒng)的 RDBMS 和 NoSQL 的最佳特性。
TiDB 兼容 MySQL，支持無(wú)限的水平擴(kuò)展，具備強(qiáng)一致性和高可用性。
TiDB 的目標(biāo)是為 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 場(chǎng)景提供一站式的解決方案。
核心特性
- 金融級(jí)高可用
- 在線水平擴(kuò)容或者縮容，并且存算分離
- 云原生的分布式數(shù)據(jù)庫(kù)，支持部署在公有云，私有云，混合云中
- 實(shí)時(shí)HTAP，提供TIKV行存儲(chǔ)引擎和TiFlash列存儲(chǔ)引擎
- 兼容MySQL協(xié)議和MySQL生態(tài)
- 分布式事務(wù)強(qiáng)一致性
- 從 MySQL 無(wú)縫切換到 TiDB，幾乎無(wú)需修改代碼，遷移成本極低
- PD在分布式理論CAP方面滿足CP，是強(qiáng)一致性的
系統(tǒng)架構(gòu)
TiDB 集群主要包括三個(gè)核心組件：TiDB Server，PD Server 和 TiKV Server
TiDB Server
TiDB Server 負(fù)責(zé)接收 SQL 請(qǐng)求，處理 SQL 相關(guān)的邏輯，并通過(guò) PD 找到存儲(chǔ)計(jì)算所需數(shù)據(jù)的 TiKV 地址，與 TiKV 交互獲取數(shù)據(jù)，最終返回結(jié)果。TiDB Server 是無(wú)狀態(tài)的，其本身并不存儲(chǔ)數(shù)據(jù)，只負(fù)責(zé)計(jì)算，可以無(wú)限水平擴(kuò)展，可以通過(guò)負(fù)載均衡組件（如LVS、HAProxy 或 F5）對(duì)外提供統(tǒng)一的接入地址。
PD Server
Placement Driver (簡(jiǎn)稱 PD) 是整個(gè)集群的管理模塊，其主要工作有三個(gè)：一是存儲(chǔ)集群的元信息（某個(gè) Key 存儲(chǔ)在哪個(gè) TiKV 節(jié)點(diǎn)）；二是對(duì) TiKV 集群進(jìn)行調(diào)度和負(fù)載均衡（如數(shù)據(jù)的遷移、Raft group leader 的遷移等）；三是分配全局唯一且遞增的事務(wù) ID。
PD 通過(guò) Raft 協(xié)議保證數(shù)據(jù)的安全性。Raft 的 leader server 負(fù)責(zé)處理所有操作，其余的 PD server 僅用于保證高可用。建議部署奇數(shù)個(gè) PD 節(jié)點(diǎn)。
TiKV Server
TiKV Server 負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，從外部看 TiKV 是一個(gè)分布式的提供事務(wù)的 Key-Value 存儲(chǔ)引擎。存儲(chǔ)數(shù)據(jù)的基本單位是 Region，每個(gè) Region 負(fù)責(zé)存儲(chǔ)一個(gè) Key Range（從 StartKey 到 EndKey 的左閉右開(kāi)區(qū)間）的數(shù)據(jù)，每個(gè) TiKV 節(jié)點(diǎn)會(huì)負(fù)責(zé)多個(gè) Region。TiKV 使用 Raft 協(xié)議做復(fù)制，保持?jǐn)?shù)據(jù)的一致性和容災(zāi)。副本以 Region 為單位進(jìn)行管理，不同節(jié)點(diǎn)上的多個(gè) Region 構(gòu)成一個(gè) Raft Group，互為副本。數(shù)據(jù)在多個(gè) TiKV 之間的負(fù)載均衡由 PD 調(diào)度，這里也是以 Region 為單位進(jìn)行調(diào)度。
TiKV如何做到數(shù)據(jù)不丟失？
簡(jiǎn)單理解，就是把數(shù)據(jù)復(fù)制到多臺(tái)機(jī)器上，這樣一個(gè)節(jié)點(diǎn)down 機(jī)，其他節(jié)點(diǎn)上的副本還能繼續(xù)提供服務(wù)；復(fù)雜理解，需要這個(gè)數(shù)據(jù)可靠并且高效復(fù)制到其他節(jié)點(diǎn)，并且能處理副本失效的情況，那怎么做呢，就是使用 Raft一致性算法
與MySQL的對(duì)比
支持的特性
- 支持分布式事務(wù)，原理是基于Google Percolator，Percolator是基于Bigtable的，所以數(shù)據(jù)結(jié)構(gòu)直接使用了Bigtable的Tablet。
- 支持鎖，TIDB是樂(lè)觀鎖 +MVCC ，MySQL是悲觀鎖+MVCC，要注意TIDB執(zhí)行Update、Insert、Delete時(shí)不會(huì)檢查沖突，只有在提交時(shí)才會(huì)檢查寫寫沖突，所以在業(yè)務(wù)端執(zhí)行SQL語(yǔ)句后，要注意檢查返回值，即使執(zhí)行沒(méi)有出錯(cuò)，提交的時(shí)候也可能出錯(cuò)。
不支持的功能特性
- 不支持存儲(chǔ)過(guò)程、函數(shù)、觸發(fā)器
- 自增id只支持在單個(gè)TIDB Server的自增，不支持多個(gè)TIDB Server的自增。
- 外鍵約束
- 臨時(shí)表
- XA 語(yǔ)法（TiDB 內(nèi)部使用兩階段提交，但并沒(méi)有通過(guò) SQL 接口公開(kāi)）
總結(jié)
如果貴司的數(shù)據(jù)量比較大，正在考慮要分庫(kù)分表，那么完全可以使用它，來(lái)避免分庫(kù)分表，分庫(kù)分表是一個(gè)過(guò)渡方案，使用分布式數(shù)據(jù)庫(kù)才是終極方案。同時(shí)如果貴司的數(shù)據(jù)量比較小，那么就沒(méi)必要引入了
