作者： 數(shù)據(jù)源的TiDB學(xué)習(xí)之路 原文來源： https://tidb.net/blog/e82b2c5f

當(dāng)前的數(shù)據(jù)庫種類繁多，墨天輪當(dāng)前統(tǒng)計的所有國產(chǎn)數(shù)據(jù)庫已經(jīng)有 290個 ，其中屬于關(guān)系型數(shù)據(jù)庫的有 166個 。關(guān)系型數(shù)據(jù)庫從部署架構(gòu)上又可以分為集中式（典型代表為達夢DM8、金倉KES）、分庫分表（典型代表為中興GoldenDB、騰訊TDSQL）以及原生分布式架構(gòu)（典型代表為PingCAP TiDB、阿里OceanBase）。

昨天和別人交流PingCAP TiDB時，這位同學(xué)對“**TiDB在線擴容對業(yè)務(wù)幾乎沒有影響”**這一點表示不太理解，驚訝TiDB到底是怎么做到的。。細(xì)聊下來，發(fā)現(xiàn)這位同學(xué)是一位主要負(fù)責(zé)集中式和早期分布式架構(gòu)數(shù)據(jù)庫的DBA人員，比較熟悉Oracle、Greenplum。于是我有點理解他的驚訝了，因為Oracle和Greenplum我也是有一點點經(jīng)驗，本文簡單針對一般分布式數(shù)據(jù)庫和TiDB在擴容機制上談一點個人的理解。

一． 一般分布式數(shù)據(jù)庫在線擴容是怎么做的？

集中式數(shù)據(jù)庫因為其架構(gòu)本身的限制，一般來說想要實現(xiàn)在線擴容是比較困難的，這里暫且不予討論，我們主要了解一下一般分布式數(shù)據(jù)庫的擴容是如何進行的。不管是Greenplum這種MPP數(shù)據(jù)庫，還是其它的分庫分表數(shù)據(jù)庫，為了實現(xiàn)數(shù)據(jù)的均衡分布，通常需要在表上定義相關(guān)的分布鍵。通過分布鍵，再結(jié)合哈希算法，可以把數(shù)據(jù)哈希散列到不同的數(shù)據(jù)節(jié)點中，類似于 hash（key）% N（key代表分布鍵，N代表數(shù)據(jù)節(jié)點編號） 。舉個例子，假如一個分布式數(shù)據(jù)庫有3個數(shù)據(jù)節(jié)點，表的分布鍵為ID（ID是一個遞增序列），那么基于哈希算法散列后數(shù)據(jù)的分布大致如下圖所示：

現(xiàn)在我們需要擴容一個節(jié)點，從原來的3節(jié)點擴容到4節(jié)點。為了保證原來哈希散列結(jié)果的一致性數(shù)據(jù)需要重新平衡，平衡后的數(shù)據(jù)分布應(yīng)該如下面圖中所示?？梢园l(fā)現(xiàn)，這個時候大部分的數(shù)據(jù)基本都搬遷了一遍。先不說數(shù)據(jù)的遷移是否對業(yè)務(wù)造成阻塞，光是這現(xiàn)有的大面積數(shù)據(jù)均衡足以導(dǎo)致整個系統(tǒng)的IO消耗極高， 嚴(yán)重影響整個系統(tǒng)的可用性 。

Greenplum在官方文檔中還明確指出“ 正在被重新分布的表或者分區(qū)會被鎖定并且不可讀寫。 當(dāng)其重新分布完成后，常規(guī)操作才會繼續(xù)。 ”可以明確的說，Greenplum早期版本里面根本就不支持所謂的“**在線”**擴容。

時代在進步，數(shù)據(jù)庫技術(shù)也在進步。為了盡可能實現(xiàn)在線擴容的能力，Greenplum數(shù)據(jù)庫包括其他的分庫分表數(shù)據(jù)庫開始引入一些新的算法來優(yōu)化此事。 一致性哈希算法 開始被普遍應(yīng)用，它與傳統(tǒng)哈希算法最主要的不同是 不再使用節(jié)點編號來進行散列 ，而是使用2^32這樣一個固定值做取模運算。一致性哈希算法將表中的數(shù)據(jù)和節(jié)點編號映射到一個圓環(huán)上，當(dāng)增加節(jié)點時影響的數(shù)據(jù)范圍只是圓環(huán)上的一小段數(shù)據(jù)范圍。比如下圖中增加節(jié)點4，影響的數(shù)據(jù)只有節(jié)點1到節(jié)點4之間的這部分?jǐn)?shù)據(jù)。

一致性哈希算法解決了數(shù)據(jù)重分布時大量數(shù)據(jù)搬遷的問題，減少了數(shù)據(jù)搬遷時的網(wǎng)絡(luò)IO和磁盤IO。不過要真正實現(xiàn)不影響業(yè)務(wù)，還需要改進數(shù)據(jù)重分布內(nèi)部的機制，比如 重分布時鎖表等 問題。

二． TiDB的擴容是怎么做的以及為什么它幾乎不影響業(yè)務(wù)？

TiDB的擴容機制離不開TiDB整體的架構(gòu)實現(xiàn)。作為一個存算分離的原生分布式架構(gòu)，TiDB集群主要由三大模塊構(gòu)成：用于集群元數(shù)據(jù)管理及集群調(diào)度的PD、用于接收外部請求并解析編譯執(zhí)行SQL的計算引擎TiDB Server以及用于數(shù)據(jù)存儲以及多副本數(shù)據(jù)一致性保證的存儲引擎TiKV/TiFlash。

基于存算分離的架構(gòu)，TiDB可以單獨進行計算層擴容和存儲層擴容。計算層的擴容相對簡單，因為TiDB Server本身是 無狀態(tài) 的。TiDB Server節(jié)點 不持久化數(shù)據(jù) ，每個節(jié)點也是 完全對等 的，當(dāng)TiDB Server計算資源不夠了，只需要增加TiDB Server節(jié)點，然后修改上層的負(fù)載均衡組件將客戶端連接均衡分發(fā)到新的TiDB Server節(jié)點即可（目前大多數(shù)負(fù)載均衡組件都支持動態(tài)修改配置）。因此， 計算節(jié)點的擴容完全不會影響現(xiàn)有的業(yè)務(wù)。

針對存儲節(jié)點，TiKV的擴容與一般分布式數(shù)據(jù)庫的擴容機制是完全不同的，這主要因為TiKV是一種 基于Multi Raft協(xié)議的分布式存儲引擎 ，而不是像Greenplum或分庫分表那種底層是多個MySQL或PG的單機數(shù)據(jù)庫。

假如某集群要從3個TiKV節(jié)點擴容到4個TiKV節(jié)點，擴容步驟大致可以概括如下：

1.?**擴容TiKV節(jié)點。**集群增加一個TiKV 4節(jié)點，此時TiKV 4上沒有任何Region。PD節(jié)點識別到新的TiKV節(jié)點啟動負(fù)載調(diào)度機制，計算哪些Region需要遷移到TiKV４。

2. **調(diào)度算法確定遷移Region。**PD節(jié)點根據(jù)調(diào)度機制，確定將哪些Region副本遷移到TiKV 4上（假如開始3個節(jié)點上各有6個Region，平均到4個節(jié)點后每個節(jié)點的Region數(shù)為18/4=4~5個副本）。PD對TiKV1~3上Region對應(yīng)的Leader副本發(fā)起復(fù)制指令。

**3. 復(fù)制Region到新節(jié)點。**在TiKV上創(chuàng)建要復(fù)制的Region的副本，通過Raft機制開始復(fù)制數(shù)據(jù)。此過程中應(yīng)用讀寫訪問不受影響，不過因復(fù)制過程產(chǎn)生的IO消耗可能會對性能產(chǎn)生一點影響，不過TiDB本身提供了流控，可以動態(tài)調(diào)整復(fù)制的速度。

**4. 刪除多余Region。**Region復(fù)制完成且數(shù)據(jù)一致后，PD將發(fā)起刪除原有副本指令，保證每個Region的副本只有3個。

**5. Leader重新均衡。**PD根據(jù)調(diào)度機制，需要均衡Leader副本，將一部分Region的Leader切換到新增節(jié)點TiKV 4上，保證Leader的均衡。Leader切換完成后，讀寫業(yè)務(wù)將自動路由到TiKV 4上實現(xiàn)業(yè)務(wù)負(fù)載均衡。

上述步驟簡單理解下來就是說，TiKV的擴容是一種 先生成副本再遷移Leader 的一個過程，擴容對業(yè)務(wù)有影響的地方主要在于生成副本產(chǎn)生的IO消耗以及Leader切換的影響。對于前者，數(shù)據(jù)庫有流控機制可以保證對業(yè)務(wù)幾乎沒有影響；對于后者，一方面Leader的切換本身時間非常短，另一方面當(dāng)TiDB意識到Region遷移后也能夠通過內(nèi)部重試保證前端業(yè)務(wù)的正常執(zhí)行。因此， 存儲節(jié)點的擴容也幾乎不會影響現(xiàn)有的業(yè)務(wù)。