數(shù)據(jù)庫軟件架構(gòu)設(shè)計(jì)些什么

一、基本概念

---

概念一“單庫”

概念二“分片”

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

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

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

（1）范圍：range

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

缺點(diǎn)：各庫壓力不均（新號段更活躍）

（2）哈希：hash

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

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

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

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

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

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

概念三“分組”

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

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

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

---

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

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

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

（3）如何保證一致性

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

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

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

如何保證站點(diǎn)的可用性？復(fù)制站點(diǎn)，冗余站點(diǎn)

如何保證服務(wù)的可用性？復(fù)制服務(wù)，冗余服務(wù)

如何保證數(shù)據(jù)的可用性？復(fù)制數(shù)據(jù)，冗余數(shù)據(jù)

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

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

冗余讀庫

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

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

如何保證數(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ò)展讀性能？

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

寫庫不建立索引；

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

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

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

（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的讀操作也路由到主庫上。

這個方案的缺點(diǎn)是，數(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)驗(yàn)“主從同步延時窗口時間”后，再次發(fā)起一個異步淘汰cache的請求

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

除此之外，58同城的最佳實(shí)踐之一是：建議為所有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ò)展。