一、緣起
（1）併發量大，流量大的網際網路架構，一般來說，資料庫上層都有乙個服務層，服務層記錄了「業務庫名」與「資料庫例項」的對映關係，通過資料庫連線池向資料庫路由sql語句以執行：
如上圖：服務層配置使用者庫user對應的資料庫例項物理位置為ip（其實是乙個內網網域名稱）。
（2）隨著資料量的增大，資料要進行水平切分，分庫後將資料分布到不同的資料庫例項（甚至物理機器）上，以達到降低資料量，增強效能的擴容目的：
如上圖：使用者庫user分布在兩個例項上，ip0和ip1，服務層通過使用者標識uid取模的方式進行尋庫路由，模2餘0的訪問ip0上的user庫，模2餘1的訪問ip1上的user庫。
關於資料庫水平切分，垂直切分的更多細節，詳見《一分鐘掌握資料庫垂直拆分》 。
（3）網際網路架構需要保證資料庫高可用，常見的一種方式，使用雙主同步+keepalived+虛ip的方式保證資料庫的可用性：
如上圖：兩個相互同步的主庫使用相同的虛ip。
如上圖：當主庫掛掉的時候，虛ip自動漂移到另乙個主庫，整個過程對呼叫方透明，通過這種方式保證資料庫的高可用。
關於高可用的更多細節，詳見《究竟啥才是網際網路架構「高可用」》。
（4）綜合上文的（2）和（3），線上實際的架構，既有水平切分，又有高可用保證，所以實際的資料庫架構是這樣的：
提問：如果資料量持續增大，分2個庫效能扛不住了，該怎麼辦呢？
二、停服務方案
在討論平滑方案之前，先簡要說明下「x庫拆y庫」停服務的方案：
（1）站點掛乙個公告「為了為廣大使用者提供更好的服務，本站點/遊戲將在今晚00:00-2:00之間公升級，屆時將不能登入，使用者周知」
（2）停服務
（3）新建y個庫，做好高可用
（4）資料遷移，重新分布，寫乙個資料遷移程式，從x個庫里匯入到y個庫里，路由規則由%x公升級為%y
（5）修改服務配置，原來x行配置公升級為y行
（6）重啟服務，連線新庫重新對外提供服務
整個過程中，最耗時的是第四步資料遷移。
回滾方案：
如果資料遷移失敗，或者遷移後測試失敗，則將配置改回x庫，恢復服務，改天再掛公告。
方案優點：簡單
方案缺點：
（1）停服務，不高可用
（2）技術同學壓力大，所有工作要在規定時間內做完，根據經驗，壓力越大約容易出錯（這一點很致命）
（3）如果有問題第一時間沒檢查出來，啟動了服務，執行一段時間後再發現有問題，難以回滾，需要回檔，可能會丟失一部分資料
有沒有更平滑的方案呢？
三、秒級、平滑、帥氣方案
再次看一眼擴容前的架構，分兩個庫，假設每個庫1億資料量，如何平滑擴容，增加例項數，降低單庫資料量呢？三個簡單步驟搞定。
（1）修改配置
主要修改兩處：
a）資料庫例項所在的機器做雙虛ip，原來%2=0的庫是虛ip0，現在增加乙個虛ip00，%2=1的另乙個庫同理
b）修改服務的配置（不管是在配置檔案裡，還是在配置中心），將2個庫的資料庫配置，改為4個庫的資料庫配置，修改的時候要注意舊庫與辛苦的對映關係：
%2=0的庫，會變為%4=0與%4=2；
%2=1的部分，會變為%4=1與%4=3；
這樣修改是為了保證，拆分後依然能夠路由到正確的資料。
（2）reload配置，例項擴容
服務層reload配置，reload可能是這麼幾種方式：
a）比較原始的，重啟服務，讀新的配置檔案
b）高階一點的，配置中心給服務發訊號，重讀配置檔案，重新初始化資料庫連線池
不管哪種方式，reload之後，資料庫的例項擴容就完成了，原來是2個資料庫例項提供服務，現在變為4個資料庫例項提供服務，這個過程一般可以在秒級完成。
整個過程可以逐步重啟，對服務的正確性和可用性完全沒有影響：
a）即使%2尋庫和%4尋庫同時存在，也不影響資料的正確性，因為此時仍然是雙主資料同步的
b）服務reload之前是不對外提供服務的，冗餘的服務能夠保證高可用
完成了例項的擴充套件，會發現每個資料庫的資料量依然沒有下降，所以第三個步驟還要做一些收尾工作。
（3）收尾工作，資料收縮
有這些一些收尾工作：
a）把雙虛ip修改回單虛ip
b）解除舊的雙主同步，讓成對庫的資料不再同步增加
c）增加新的雙主同步，保證高可用
d）刪除掉冗餘資料，例如：ip0裡%4=2的資料全部乾掉，只為%4=0的資料提供服務啦
這樣下來，每個庫的資料量就降為原來的一半，資料收縮完成。
四、總結
該帥氣方案能夠實現n庫擴2n庫的秒級、平滑擴容，增加資料庫服務能力，降低單庫一半的資料量，其核心原理是：成倍擴容，避免資料遷移。
遷移步驟：
（1）修改配置
（2）reload配置，例項擴容完成
（3）刪除冗餘資料等收尾工作，資料量收縮完成
希望大夥有收穫，好文值得**。
mysql秒級平滑 資料庫秒級平滑擴容架構方案
一 緣起 1 併發量大，流量大的網際網路架構，一般來說，資料庫上層都有乙個服務層，服務層記錄了 業務庫名 與 資料庫例項 的對映關係，通過資料庫連線池向資料庫路由sql語句以執行 如上圖 服務層配置使用者庫user對應的資料庫例項物理位置為ip 其實是乙個內網網域名稱 2 隨著資料量的增大，資料要進...
mysql秒級平滑 資料庫秒級平滑擴容架構方案
一 緣起 1 併發量大，流量大的網際網路架構，一般來說，資料庫上層都有乙個服務層，服務層記錄了 業務庫名 與 資料庫例項 的對映關係，通過資料庫連線池向資料庫路由sql語句以執行 如上圖 服務層配置使用者庫user對應的資料庫例項物理位置為ip 其實是乙個內網網域名稱 2 隨著資料量的增大，資料要進...
mysql秒級平滑 資料庫秒級平滑擴容架構方案
一 緣起 1 併發量大，流量大的網際網路架構，一般來說，資料庫上層都有乙個服務層，服務層記錄了 業務庫名 與 資料庫例項 的對映關係，通過資料庫連線池向資料庫路由sql語句以執行 如上圖 服務層配置使用者庫user對應的資料庫例項物理位置為ip 其實是乙個內網網域名稱 2 隨著資料量的增大，資料要進...