程式教學

數據庫軟件架構設計些什麽

一、基本概念

二、數據庫架構設計思路

(1)可用性

(2)讀性能

(3)一致性

(4)擴展性

一、基本概念

概念一“單庫”

概念二“分片”

分片解決的是“數據量太大”的問題,也就是通常說的“水平切分”。

一旦引入分片,勢必有“數據路由”的概念,哪個數據訪問哪個庫。

路由規則通常有3種方法:

(1)範圍:range

優點:簡單,容易擴展

缺點:各庫壓力不均(新號段更活躍)

(2)哈希:hash

優點:簡單,數據均衡,負載均勻

缺點:遷移麻煩(2庫擴3庫數據要遷移)

(3)路由服務:router-config-server

優點:靈活性強,業務與路由算法解耦

缺點:每次訪問數據庫前多一次查詢

大部分互聯網公司采用的方案二:哈希分庫,哈希路由

概念三“分組”

分組解決“可用性”問題,分組通常通過主從複制的方式實現。

互聯網公司數據庫實際軟件架構是:又分片,又分組(如下圖)

二、數據庫架構設計思路

數據庫軟件架構師平時設計些什麽東西呢?至少要考慮以下四點:

(1)如何保證數據可用性

(2)如何提高數據庫讀性能(大部分應用讀多寫少,讀會先成為瓶頸)

(3)如何保證一致性

(4)如何提高擴展性

2.1如何保證數據的可用性?
解決可用性問題的思路是=>冗余

如何保證站點的可用性?複制站點,冗余站點

如何保證服務的可用性?複制服務,冗余服務

如何保證數據的可用性?複制數據,冗余數據

數據的冗余,會帶來一個副作用=>引發一致性問題(先不說一致性問題,先說可用性)

如何保證數據庫“讀”高可用?
冗余讀庫

冗余讀庫帶來的副作用?讀寫有延時,可能不一致

上面這個圖是很多互聯網公司mysql的架構,寫仍然是單點,不能保證寫高可用。

如何保證數據庫“寫”高可用?
冗余寫庫

采用雙主互備的方式,可以冗余寫庫

帶來的副作用?雙寫同步,數據可能沖突(例如“自增id”同步沖突),如何解決同步沖突,有兩種常見解決方案:

(1)兩個寫庫使用不同的初始值,相同的步長來增加id:1寫庫的id為0,2,4,6...;2寫庫的id為1,3,5,7…

(2)不使用數據的id,業務層自己生成唯一的id,保證數據不沖突

58同城沒有使用上述兩種架構來做讀寫的“高可用”,58同城采用的是“雙主當主從用”的方式:

仍是雙主,但只有一個主提供服務(讀+寫),另一個主是“shadow-master”,只用來保證高可用,平時不提供服務。

master掛了,shadow-master頂上(vip漂移,對業務層透明,不需要人工介入)

這種方式的好處:

1)讀寫沒有延時

2)讀寫高可用

不足:

1)不能通過加從庫的方式擴展讀性能

2)資源利用率為50%,一臺冗余主沒有提供服務

那如何提高讀性能呢?進入第二個話題,如何提供讀性能。

2.2如何擴展讀性能?
提高讀性能的方式大致有三種,第一種是建立索引。這種方式不展開,要提到的一點是,不同的庫可以建立不同的索引。

寫庫不建立索引;

線上讀庫建立線上訪問索引,例如uid;

線下讀庫建立線下訪問索引,例如time;

第二種擴充讀性能的方式是,增加從庫,這種方法大家用的比較多,但是,存在兩個缺點:

(1)從庫越多,同步越慢

(2)同步越慢,數據不一致窗口越大(不一致後面說,還是先說讀性能的提高)

58同城沒有采用這種方法提高數據庫讀性能(沒有從庫),采用的是增加緩存。常見的緩存架構如下:

上遊是業務應用,下遊是主庫,從庫(讀寫分離),緩存。

58同城的玩法是:服務+數據庫+緩存一套

業務層不直接面向db和cache,服務層屏蔽了底層db、cache的複雜性。為什麽要引入服務層,今天不展開,58采用了“服務+數據庫+緩存一套”的方式提供數據訪問,用cache提高讀性能。

不管采用主從的方式擴展讀性能,還是緩存的方式擴展讀性能,數據都要複制多份(主+從,db+cache),一定會引發一致性問題。

2.3如何保證一致性?
主從數據庫的一致性,通常有兩種解決方案:

(1)中間件

如果某一個key有寫操作,在不一致時間窗口內,中間件會將這個key的讀操作也路由到主庫上。

這個方案的缺點是,數據庫中間件的門檻較高(百度,騰訊,阿里,360等一些公司有,當然58也有)

(2)強制讀主

58的“雙主當主從用”的架構,不存在主從不一致的問題。

第二類不一致,是db與緩存間的不一致

常見的緩存架構如上,此時寫操作的順序是:

(1)淘汰cache

(2)寫數據庫

讀操作的順序是:

(1)讀cache,如果cache hit則返回

(2)如果cache miss,則讀從庫

(3)讀從庫後,將數據放回cache

在一些異常時序情況下,有可能從【從庫讀到舊數據(同步還沒有完成),舊數據入cache後】,數據會長期不一致。

解決辦法是“緩存雙淘汰”,寫操作時序升級為:

(1)淘汰cache

(2)寫數據庫

(3)在經驗“主從同步延時窗口時間”後,再次發起一個異步淘汰cache的請求

這樣,即使有臟數據如cache,一個小的時間窗口之後,臟數據還是會被淘汰。帶來的代價是,多引入一次讀miss(成本可以忽略)。

除此之外,58同城的最佳實踐之一是:建議為所有cache中的item設置一個超時時間。

說完一致性,最後一個話題是擴展性。

2.4如何提高數據庫的擴展性?
原來用hash的方式路由,分為2個庫,數據量還是太大,要分為3個庫,勢必需要進行數據遷移,58同城有一個很帥氣的“數據庫秒級擴容”方案。

如何秒級擴容?

首先,我們不做2庫變3庫的擴容,我們做2庫變4庫(庫加倍)的擴容(未來4->8->16)

服務+數據庫是一套(省去了緩存)

數據庫采用“雙主”的模式。

擴容步驟:

第一步,將一個主庫提升

第二步,修改配置,2庫變4庫(原來MOD2,現在配置修改後MOD4)

擴容完成

原MOD2為偶的部分,現在會MOD4余0或者2

原MOD2為奇的部分,現在會MOD4余1或者3

數據不需要遷移,同時,雙主互相同步,一遍是余0,一邊余2,兩邊數據同步也不會沖突,秒級完成擴容!

最後,要做一些收尾工作:

(1)將舊的雙主同步解除

(2)增加新的雙主(雙主是保證可用性的,shadow-master平時不提供服務)

(3)刪除多余的數據(余0的主,可以將余2的數據刪除掉)

這樣,秒級別內,我們就完成了2庫變4庫的擴展。

OK,今天主要分享了58同城,數據庫軟件架構上:

(1)如何保證數據可用性

(2)如何提高數據庫讀性能

(3)如何保證數據一致性

(4)如何進行秒級擴容

希望大家有收獲,謝謝大家!

Leave a Reply

Your email address will not be published.