起因
每一個項目都是由小項目發展而來，從最初的一台數據庫，到后面的幾千上萬台數據庫，這發展的過程，我們都要涉及到一個技術問題：當數據量太大的時候，如何進行擴容？
案例
小明現在負責一個站點，用戶數據庫有2個，網站用戶數據通過ID取模，分別存在兩台用戶數據庫中，現在數據增大，兩台數據庫已經不夠用了，現在需要增加數據庫進行擴容，小明應該如何進行擴容？
方案
- 停機擴容
- 平滑擴容
停機擴容
我們先來了解下停機擴容方案，這是一種很多人初期都會使用的方案（幾台數據庫的時候），具體步驟：
- 小明先掛公告，告訴大家明天的凌晨02：00 - 06：00，站點將停機升級；
- 時間到了，小明停止了所有對外服務；
- 小明新增了2個數據庫，然后寫了一個程序，將原先的2個庫的數據遷移到現有的4個庫（2+2）上；
- 數據遷移完成，修改數據庫服務配置；
- 重啟服務，並重新開啟對外服務。
回滾方案：
數據遷移失敗，或者遷移后測試失敗，則將服務配置修改回原先的兩個庫，改天再升級。
優點：
- 簡單
缺點：
- 不高可用
- 開啟升級到升級完成，時間短，項目組壓力大，易出錯
- 升級時間基本是半夜人流量最少的時候，項目組疲累，容易出錯
- 運行一段時間后，發現問題，難以回滾，只能回到擴容前，會丟失部分數據
適用：
- 小型網站；
- 大部分游戲；
- 對高可用要求不高的服務。
平滑擴容
現在我們來聊一下本文的重點：平滑擴容中最好的方案就是擴容的數據庫是原先數據庫的倍數，如：2個數據庫擴容到4個數據庫，是原先的2倍。步驟：
（1）新增2個數據庫
（2）配置雙主進行數據同步（先測試，后線上，重啟服務時間是秒級）
（3）數據同步完成之后，配置主主雙寫（因為同步有延遲，如果每時每刻都有數據寫入/更新的話，就不能准確的保證數據已經同步完成）
（4）數據同步完成后（時間比較長），刪除雙主同步，修改數據庫配置，並重啟（秒級）；
（5）此時已經擴容完成，但此時的數據並沒有減少，新增的數據庫跟舊的數據庫一樣多的數據，此時還需要寫一個程序，清空數據庫中多余的數據，如：
- User1去除 uid % 4 = 2的數據；
- User3去除 uid % 4 = 0的數據；
- User2去除 uid % 4 = 3的數據；
- User4去除 uid % 4 = 1的數據。
現在，我們就已經完成了數據庫的平滑擴容了。
優點
- 擴容期間，服務照常進行，保證高可用；
- 時間長，項目組壓力沒有這么大，出錯率低；
- 擴容期間，遇到什么問題，都可以隨時調試，不怕影響線上服務；
- 每個數據庫少了一半的數據量。
缺點
- 程序復雜，需要配置雙主、主主雙寫、檢測數據同步等額外技術；
- 但后期數據庫成千上萬台的時候，擴容復雜（情況非常少，除非將很多業務數據放在同一個數據庫）。
適用：
- 大型網站；
- 對高可用要求高的服務。
總結
本文主要簡單講解了數據庫擴容的兩種方案，並對這兩種方案的優缺點、適用場景進行了說明：
- 停機擴容：簡單，不高可用，易出錯，擴容后不能回滾，只能回檔，會丟失一部分數據。
- 平滑擴容：復雜，高可用，出錯調試容易，易回滾，不會造成數據丟失，
結語
- 每一種方案都有適合它的場景，適合自己的，才是最好的；
- 小編經驗有限，希望此文章對大家有幫助；
- 每天進步一點點。
參考文獻
58沈劍老師架構師之路的：數據庫秒級平滑擴容架構方案