天天看點

炸!億級資料DB秒級平滑擴容!!!

一步一步,娓娓道來。

一般來說,并發量大,吞吐量大的網際網路分層架構是怎麼樣的?

資料庫上層都有一個微服務,服務層記錄“業務庫”與“資料庫執行個體配置”的映射關系,通過資料庫連接配接池向資料庫路由sql語句。

炸!億級資料DB秒級平滑擴容!!!

如上圖所示,服務層配置使用者庫user對應的資料庫執行個體ip。

畫外音:其實是一個内網域名。

該分層架構,如何應對資料庫的高可用?

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

炸!億級資料DB秒級平滑擴容!!!

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

炸!億級資料DB秒級平滑擴容!!!

當主庫挂掉的時候,虛ip自動漂移到另一個主庫,整個過程對調用方透明,通過這種方式保證資料庫的高可用。

畫外音:關于高可用,《網際網路分層架構如何保證“高可用“?》專題介紹過,本文不再展開。

該分層架構,如何應對資料量的暴增?

随着資料量的增大,資料庫要進行水準切分,分庫後将資料分布到不同的資料庫執行個體(甚至實體機器)上,以達到降低資料量,增強性能的擴容目的。

炸!億級資料DB秒級平滑擴容!!!

如上圖所示,使用者庫user分布在兩個執行個體上,ip0和ip1,服務層通過使用者辨別uid取模的方式進行尋庫路由,模2餘0的通路ip0上的user庫,模2餘1的通路ip1上的user庫。

畫外音:此時,水準切分叢集的讀寫執行個體加倍,單個執行個體的資料量減半,性能增長可不止一倍。

綜上三點所述,大資料量,高可用的網際網路微服務分層的架構如下:

炸!億級資料DB秒級平滑擴容!!!

既有水準切分,又保證高可用。

如果資料量持續增大,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)如果有問題第一時間沒檢查出來,啟動了服務,運作一段時間後再發現有問題,則難以復原,如果回檔會丢失一部分資料;

有沒有秒級實施、更平滑、更帥氣的方案呢?

炸!億級資料DB秒級平滑擴容!!!

再次看一眼擴容前的架構,分兩個庫,假設每個庫1億資料量,如何平滑擴容,增加執行個體數,降低單庫資料量呢?三個簡單步驟搞定。

步驟一:修改配置。

炸!億級資料DB秒級平滑擴容!!!

主要修改兩處:

資料庫執行個體所在的機器做雙虛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配置,執行個體擴容。

炸!億級資料DB秒級平滑擴容!!!

服務層reload配置,reload可能是這麼幾種方式:

(a)比較原始的,重新開機服務,讀新的配置檔案;

(b)進階一點的,配置中心給服務發信号,重讀配置檔案,重新初始化資料庫連接配接池;

不管哪種方式,reload之後,資料庫的執行個體擴容就完成了,原來是2個資料庫執行個體提供服務,現在變為4個資料庫執行個體提供服務,這個過程一般可以在秒級完成。

炸!億級資料DB秒級平滑擴容!!!

整個過程可以逐漸重新開機,對服務的正确性和可用性完全沒有影響:

(a)即使%2尋庫和%4尋庫同時存在,也不影響資料的正确性,因為此時仍然是雙主資料同步的;

(b)即使%4=0與%4=2的尋庫落到同一個資料庫執行個體上,也不影響資料的正确性,因為此時仍然是雙主資料同步的;

完成了執行個體的擴充,會發現每個資料庫的資料量依然沒有下降,是以第三個步驟還要做一些收尾工作。

畫外音:這一步,資料庫執行個體個數加倍了。

步驟三:收尾工作,資料收縮。

炸!億級資料DB秒級平滑擴容!!!

有這些一些收尾工作:

(a)把雙虛ip修改回單虛ip;

(b)解除舊的雙主同步,讓成對庫的資料不再同步增加;

(c)增加新的雙主同步,保證高可用;

(d)删除掉備援資料,例如:ip0裡%4=2的資料全部删除,隻為%4=0的資料提供服務;

畫外音:這一步,資料庫單執行個體資料量減半了。

總結

炸!億級資料DB秒級平滑擴容!!!

網際網路大資料量,高吞吐量,高可用微服務分層架構,資料庫實作秒級平滑擴容的三個步驟為:

(1)修改配置(雙虛ip,微服務資料庫路由);

(2)reload配置,執行個體增倍完成;

(3)删除備援資料等收尾工作,資料量減半完成;

思路比結論重要,希望大家有收獲。

炸!億級資料DB秒級平滑擴容!!!

架構師之路-分享技術思路