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