[[177326]]

一、基本概念

二、數(shù)據(jù)庫架構(gòu)設(shè)計思路

(1)可用性

(2)讀性能

(3)一致性

(4)擴(kuò)展性

一、基本概念

概念一“單庫”

概念二“分片”

分片解決的是“數(shù)據(jù)量太大”的問題，也就是通常說的“水平切分”。

一旦引入分片，勢必有“數(shù)據(jù)路由”的概念，哪個數(shù)據(jù)訪問哪個庫。

路由規(guī)則通常有3種方法：

(1)范圍：range

優(yōu)點：簡單，容易擴(kuò)展

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

(2)哈希：hash

優(yōu)點：簡單，數(shù)據(jù)均衡，負(fù)載均勻

缺點：遷移麻煩(2庫擴(kuò)3庫數(shù)據(jù)要遷移)

(3)路由服務(wù)：router-config-server

優(yōu)點：靈活性強(qiáng)，業(yè)務(wù)與路由算法解耦

缺點：每次訪問數(shù)據(jù)庫前多一次查詢

大部分互聯(lián)網(wǎng)公司采用的方案二：哈希分庫，哈希路由

概念三“分組”

分組解決“可用性”問題，分組通常通過主從復(fù)制的方式實現(xiàn)。

互聯(lián)網(wǎng)公司數(shù)據(jù)庫實際軟件架構(gòu)是：又分片，又分組(如下圖)

二、數(shù)據(jù)庫架構(gòu)設(shè)計思路

數(shù)據(jù)庫軟件架構(gòu)師平時設(shè)計些什么東西呢?至少要考慮以下四點：

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

(2)如何提高數(shù)據(jù)庫讀性能(大部分應(yīng)用讀多寫少，讀會先成為瓶頸)

(3)如何保證一致性

(4)如何提高擴(kuò)展性

2.1如何保證數(shù)據(jù)的可用性?

解決可用性問題的思路是=>冗余

• 如何保證站點的可用性?復(fù)制站點，冗余站點
• 如何保證服務(wù)的可用性?復(fù)制服務(wù)，冗余服務(wù)
• 如何保證數(shù)據(jù)的可用性?復(fù)制數(shù)據(jù)，冗余數(shù)據(jù)

數(shù)據(jù)的冗余，會帶來一個副作用=>引發(fā)一致性問題(先不說一致性問題，先說可用性)

如何保證數(shù)據(jù)庫“讀”高可用?

冗余讀庫

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

上面這個圖是很多互聯(lián)網(wǎng)公司mysql的架構(gòu)，寫仍然是單點，不能保證寫高可用。

如何保證數(shù)據(jù)庫“寫”高可用?

冗余讀庫

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

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

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

(2)不使用數(shù)據(jù)的id，業(yè)務(wù)層自己生成唯一的id，保證數(shù)據(jù)不沖突

58同城沒有使用上述兩種架構(gòu)來做讀寫的“高可用”，58同城采用的是“雙主當(dāng)主從用”的方式：

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

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

這種方式的好處：

1)讀寫沒有延時

2)讀寫高可用

不足：

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

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

那如何提高讀性能呢?進(jìn)入第二個話題，如何提供讀性能。

2.2如何擴(kuò)展讀性能?

提高讀性能的方式大致有三種，***種是建立索引。這種方式不展開，要提到的一點是，不同的庫可以建立不同的索引。

寫庫不建立索引;

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

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

第二種擴(kuò)充讀性能的方式是，增加從庫，這種方法大家用的比較多，但是，存在兩個缺點：

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

(2)同步越慢，數(shù)據(jù)不一致窗口越大(不一致后面說，還是先說讀性能的提高)

58同城沒有采用這種方法提高數(shù)據(jù)庫讀性能(沒有從庫)，采用的是增加緩存。常見的緩存架構(gòu)如下：

上游是業(yè)務(wù)應(yīng)用，下游是主庫，從庫(讀寫分離)，緩存。

58同城的玩法是：服務(wù)+數(shù)據(jù)庫+緩存一套

業(yè)務(wù)層不直接面向db和cache，服務(wù)層屏蔽了底層db、cache的復(fù)雜性。為什么要引入服務(wù)層，今天不展開，58采用了“服務(wù)+數(shù)據(jù)庫+緩存一套”的方式提供數(shù)據(jù)訪問，用cache提高讀性能。

不管采用主從的方式擴(kuò)展讀性能，還是緩存的方式擴(kuò)展讀性能，數(shù)據(jù)都要復(fù)制多份(主+從，db+cache)，一定會引發(fā)一致性問題。

2.3如何保證一致性?

主從數(shù)據(jù)庫的一致性，通常有兩種解決方案：

(1)中間件

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

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

(2)強(qiáng)制讀主

58的“雙主當(dāng)主從用”的架構(gòu)，不存在主從不一致的問題。

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

常見的緩存架構(gòu)如上，此時寫操作的順序是：

(1)淘汰cache

(2)寫數(shù)據(jù)庫

讀操作的順序是：

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

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

(3)讀從庫后，將數(shù)據(jù)放回cache

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

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

(1)淘汰cache

(2)寫數(shù)據(jù)庫

(3)在經(jīng)驗“主從同步延時窗口時間”后，再次發(fā)起一個異步淘汰cache的請求

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

除此之外，58同城的***實踐之一是：建議為所有cache中的item設(shè)置一個超時時間。

說完一致性，***一個話題是擴(kuò)展性。

2.4如何提高數(shù)據(jù)庫的擴(kuò)展性?

原來用hash的方式路由，分為2個庫，數(shù)據(jù)量還是太大，要分為3個庫，勢必需要進(jìn)行數(shù)據(jù)遷移，58同城有一個很帥氣的“數(shù)據(jù)庫秒級擴(kuò)容”方案。

如何秒級擴(kuò)容?

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

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

數(shù)據(jù)庫采用“雙主”的模式。

擴(kuò)容步驟：

***步，將一個主庫提升

第二步，修改配置，2庫變4庫(原來MOD2，現(xiàn)在配置修改后MOD4)

擴(kuò)容完成

原MOD2為偶的部分，現(xiàn)在會MOD4余0或者2

原MOD2為奇的部分，現(xiàn)在會MOD4余1或者3

數(shù)據(jù)不需要遷移，同時，雙主互相同步，一遍是余0，一邊余2，兩邊數(shù)據(jù)同步也不會沖突，秒級完成擴(kuò)容!

***，要做一些收尾工作：

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

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

(3)刪除多余的數(shù)據(jù)(余0的主，可以將余2的數(shù)據(jù)刪除掉)

這樣，秒級別內(nèi)，我們就完成了2庫變4庫的擴(kuò)展。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】