58沈劍架構系列 資料庫秒級平滑擴容架構方案

2022-01-18 01:50:21 字數 3577 閱讀 9350

一、緣起

(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 隨著資料量的增大,資料要進...