[[398632]]

本文轉載自微信公眾號「sowhat1412」，作者sowhat1412。轉載本文請聯系sowhat1412公眾號。

引言

初版

如果我們的線上服務不重要，一般來個單體的數據庫DB來存儲數據即可來。

單體應用

優點：簡單，省事，方便。

缺點：數據并發性，穩定性都有問題。

進階

隨著數據量的不斷增大，一般我們要對數據進行水平切分，水平切分的規則你可以簡單根據用戶id或者用戶IP對數據進行取模，實現路由功能。當然也可以增加Slave跟KeepAlived來實現高可用。

主從+路由

但問題是，如果隨著業務發展，目前我們2個庫的性能扛不住了，還要繼續水平拆分，造出更多庫咋辦?你一般是如何實現絲滑擴容的呢?

擴容

第一版：停機擴容

停機擴容

簡單直接暴力的方法。

• APP通知用戶在某個時間段停機維護升級。
• 新建若干個具有高可用的庫。
• 停止當前服務，然后寫個數據遷移程序，實現把老庫數據全部遷移到新庫中。
• 修改代碼路由規則后重新對外提供服務。

優點：簡單

缺點：中間停服務了，無法保證高可用。數據切換前跟切換過程中需確保無任何出錯。

第二版：在線雙寫

在線雙寫

1. 建立好新到數據庫，然后接下來用戶在寫原有數據庫到同時也寫一份數據到我們的新庫中。
2. 寫個數據遷移程序，實現舊庫中的歷史數據遷移到新庫中。
3. 遷移過程中，每次插入數據時，需檢測數據的更新情況。比如，如果新的表中沒有當前的數據，則直接新增;如果新表有數據并沒有我們要遷移的數據新的話，我們就更新為當前數據，只能允許新的數據覆蓋舊的數據，推薦使用Canal這樣到中間件。
4. 經過一段時間后需要校驗新庫跟舊庫兩邊數據是否一樣。如果檢查到一樣了，則直接切換即可。

優點：高可用了。

缺點：不夠絲滑，來回挪動數據較大。

第三版：絲滑般擴容

目標：打算將原來到兩個數據庫擴容到4個。

第一步：修改配置

修改配置

修改配置信息，注意舊庫跟新庫之間到映射關系。確保擴容后數據可以正確路由到服務器。

• Id % 2 = 0 的庫變為了 id % 4 = 0 或 id % 4 = 2
• Id % 2 = 1 的庫變為了 id % 4 = 1 或 id % 4 = 3

第二步：reload配置

服務層reload配置，可以重啟服務，也可以CLoud那樣配置中心發送信號來實現重讀配置文件。

至此，數據庫的2 --> 4 擴容完成，原來是2個數據庫實例提供服務，現在變為4個數據庫實例提供服務。

第三步：收縮數據

絲滑擴容

此時 id % 4 = 0 跟 id % 4 = 2 的兩個DB 還在同步數據。id % 4 = 1 跟 id % 4 = 3的兩個DB還在同步數據。需做一些收尾操作。

1. 接觸上面的兩個同步操作。
2. 對新庫新建高可用。
3. 刪除冗余數據，比如id % 4 = 0的機器中刪除id % 4 = 2的冗余數據，只為id % 4 = 0的數據提供服務，其余三個類似操作。
4. 至此實現成倍擴容，還避免來數據遷移。