為什麼說 TiDB 線上擴容對業務幾乎沒有影響

本文討論了分散式資料庫在線上擴容方面的挑戰， 詳細解釋了一般分散式資料庫和 TiDB 在擴容機制上的不同。 一般分散式資料庫在進行線上擴容時，需要重新平衡資料分佈，可能會影響系統的可用性和 IO 消耗。 相比之下，TiDB 的存算分離架構使得擴容對業務影響較小。

作者：愛喝自來水的貓 來源公眾號：資料來源的技術後花園。

昨天和別人交流 PingCAP TiDB 時，這位同學對“ TiDB 線上擴容對業務幾乎沒有影響 ” 這一點表示不太理解，驚訝 TiDB 到底是怎麼做到的。 細聊下來，發現這位同學是一位主要負責集中式和早期分散式架構資料庫的 DBA 人員，比較熟悉 Oracle、Greenplum。 於是我有點理解他的驚訝了，因為 Oracle 和 Greenplum 我也是有一點點經驗，本文簡單針對一般分散式資料庫和 TiDB 在擴容機制上談一點個人的理解。

一般分散式資料庫線上擴容是怎麼做的

集中式資料庫因為其架構本身的限制，一般來說想要實現線上擴容是比較困難的，這裡暫且不予討論，我們主要了解一下一般分散式資料庫的擴容是如何進行的。不管是 Greenplum 這種 MPP 資料庫，還是其它的分庫分表資料庫，為了實現資料的均衡分佈，通常需要在表上定義相關的分佈鍵。透過分佈鍵，再結合雜湊演算法，可以把資料雜湊雜湊到不同的資料節點中，類似於 hash （ key ） % N （ key 代表分佈鍵， N 代表資料節點編號） 。舉個例子，假如一個分散式資料庫有 3 個資料節點，表的分佈鍵為 ID （ ID 是一個遞增序列），那麼基於雜湊演算法雜湊後資料的分佈大致如下圖所示：

現在我們需要擴容一個節點，從原來的 3 節點擴容到 4 節點。為了保證原來雜湊雜湊結果的一致性資料需要重新平衡，平衡後的資料分佈應該如下面圖中所示。可以發現，這個時候大部分的資料基本都搬遷了一遍。先不說資料的遷移是否對業務造成阻塞，光是這現有的大面積資料均衡足以導致整個系統的 IO 消耗極高， 嚴重影響整個系統的可用性。

Greenplum 在官方文件中還明確指出“ 正在被重新分佈的表或者分割槽會被鎖定並且不可讀寫。當其重新分佈完成後，常規操作才會繼續 ”。可以明確的說， Greenplum 早期版本里面根本就不 支援所謂的“ 線上 ”擴容。

時代在進步，資料庫技術也在進步。為了儘可能實現線上擴容的能力， Greenplum 資料庫包括其他的分庫分表資料庫開始引入一些新的演算法來最佳化此事。 一致性雜湊演算法 開始被普遍應用，它與傳統雜湊演算法最主要的不同是 不再使用節點編號來進行雜湊 ，而是使用 2^32 這樣一個固定值做取模運算。一致性雜湊演算法將表中的資料和節點編號對映到一個圓環上，當增加節點時影響的資料範圍只是圓環上的一小段資料範圍。比如下圖中增加節點 4 ，影響的資料只有節點 1 到節點 4 之間的這部分資料。

一致性雜湊演算法解決了資料重分佈時大量資料搬遷的問題，減少了資料搬遷時的網路 IO 和磁碟 IO 。不過要真正實現不影響業務，還需要改進資料重分佈內部的機制，比如 重分佈時鎖表 等問題。

TiDB 的擴容是怎麼做的以及為什麼它幾乎不影響業務?

TiDB 的擴容機制離不開 TiDB 整體的架構實現。作為一個存算分離的原生分散式架構， TiDB 叢集主要由三大模組構成：用於叢集後設資料管理及叢集排程的 PD 、用於接收外部請求並解析編譯執行 SQL 的計算引擎 TiDB Server 以及用於資料儲存以及多副本資料一致性保證的儲存引擎 TiKV/TiFlash。

基於存算分離的架構，TiDB 可以單獨進行計算層擴容和儲存層擴容。計算層的擴容相對簡單，因為 TiDB Server 本身是無狀態的。TiDB Server 節點不持久化資料，每個節點也是完全對等的，當 TiDB Server 計算資源不夠了，只需要增加 TiDB Server 節點，然後修改上層的負載均衡元件將客戶端連線均衡分發到新的 TiDB Server 節點即可（目前大多數負載均衡元件都支援動態修改配置）。因此，計算節點的擴容完全不會影響現有的業務。

針對儲存節點， TiKV 的擴容與一般分散式資料庫的擴容機制是完全不同的，這主要因為 TiKV 是一種 基於 Multi Raft 協議的分散式儲存引擎 ，而不是像 Greenplum 或分庫分表那種底層是多個 MySQL 或 PG 的單機資料庫。

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

1. 擴容 TiKV 節點 。叢集增加一個 TiKV 4 節點，此時 TiKV 4 上沒有任何 Region。PD 節點識別到新的 TiKV 節點啟動負載排程機制，計算哪些 Region 需要遷移到 TiKV ４。

2. 排程演算法確定遷移 Region 。PD 節點根據排程機制，確定將哪些 Region 副本遷移到 TiKV 4 上（假如開始 3 個節點上各有 6 個 Region ，平均到 4 個節點後每個節點的 Region 數為 18/4=4~5 個副本）。PD 對 TiKV1~3 上 Region 對應的 Leader 副本發起複製指令。

3. 複製 Region 到新節點 。在 TiKV 上建立要複製的 Region 的副本，透過 Raft 機制開始複製資料。此過程中應用讀寫訪問不受影響，不過因複製過程產生的 IO 消耗可能會對效能產生一點影響，不過 TiDB 本身提供了流控，可以動態調整複製的速度。

4. 刪除多餘 Region 。Region 複製完成且資料一致後，PD 將發起刪除原有副本指令，保證每個 Region 的副本只有 3 個。

5. Leader 重新均衡 。PD 根據排程機制，需要均衡 Leader 副本，將一部分 Region 的 Leader 切換到新增節點 TiKV 4 上，保證 Leader 的均衡。Leader 切換完成後，讀寫業務將自動路由到 TiKV 4 上實現業務負載均衡。

上述步驟簡單理解下來就是說，TiKV 的擴容是一種 先生成副本再遷移 Leader 的一個過程，擴容對業務有影響的地方主要在於生成副本產生的 IO 消耗以及 Leader 切換的影響。對於前者，資料庫有流控機制可以保證對業務幾乎沒有影響；對於後者，一方面 Leader 的切換本身時間非常短，另一方面當 TiDB 意識到 Region 遷移後也能夠透過內部重試保證前端業務的正常執行。因此， 儲存節點的擴容也幾乎不會影響現有的業務 。