本文討論了分佈式數據庫在在線擴容方面的挑戰， 詳細解釋了一般分佈式數據庫和 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 遷移後也能夠通過內部重試保證前端業務的正常執行。因此， 存儲節點的擴容也幾乎不會影響現有的業務 。