炸！億級數據DB秒級平滑擴容

一步一步，娓娓道來。

通常來講，併發量大，吞吐量大的互聯網分層架構是怎麼樣的？

數據庫上層都有一個微服務，服務層記錄「業務庫」與「數據庫實例配置」的映射關係，經過數據庫鏈接池向數據庫路由sql語句。

 

 

如上圖所示，服務層配置用戶庫user對應的數據庫實例ip。

畫外音：實際上是一個內網域名。

該分層架構，如何應對數據庫的高可用？

數據庫高可用，很常見的一種方式，使用雙主同步+keepalived+虛ip的方式進行。

 

 

如上圖所示，兩個相互同步的主庫使用相同的虛ip。

 

 

當主庫掛掉的時候，虛ip自動漂移到另外一個主庫，整個過程對調用方透明，經過這種方式保證數據庫的高可用。

畫外音：關於高可用，《互聯網分層架構如何保證「高可用「？》專題介紹過，本文再也不展開。

該分層架構，如何應對數據量的暴增？

隨着數據量的增大，數據庫要進行水平切分，分庫後將數據分佈到不一樣的數據庫實例（甚至物理機器）上，以達到下降數據量，加強性能的擴容目的。

 

 

如上圖所示，用戶庫user分佈在兩個實例上，ip0和ip1，服務層經過用戶標識uid取模的方式進行尋庫路由，模2餘0的訪問ip0上的user庫，模2餘1的訪問ip1上的user庫。

畫外音：此時，水平切分集羣的讀寫實例加倍，單個實例的數據量減半，性能增加可不止一倍。

 

綜上三點所述，大數據量，高可用的互聯網微服務分層的架構以下：

 

 

既有水平切分，又保證高可用。

若是數據量持續增大，2個庫性能扛不住了，該怎麼辦呢？

此時，須要繼續水平拆分，拆成更多的庫，下降單庫數據量，增長庫主庫實例（機器）數量，提升性能。

新的問題來了，分紅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億數據量，如何平滑擴容，增長實例數，下降單庫數據量呢？三個簡單步驟搞定。

 

步驟一：修改配置。

 

 

主要修改兩處：

• 數據庫實例所在的機器作雙虛ip：

（1）原%2=0的庫是虛ip0，現增長一個虛ip00；

（2）原%2=1的庫是虛ip1，現增長一個虛ip11；

• 修改服務的配置，將2個庫的數據庫配置，改成4個庫的數據庫配置，修改的時候要注意舊庫與新庫的映射關係：

（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）刪除冗餘數據等收尾工做，數據量減半完成；

 

思路比結論重要

若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加個人Java高級交流：787707172，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們。