數(shù)據(jù)庫架構(gòu)是怎么設(shè)計(jì)的？
一、基本概念
二、數(shù)據(jù)庫架構(gòu)設(shè)計(jì)思路
（1）可用性
（2）讀性能
（3）一致性
（4）擴(kuò)展性
一、基本概念
概念一“單庫”
概念二“分片”
分片解決的是“數(shù)據(jù)量太大”的問題，也就是通常說的“水平切分”。
一旦引入分片，勢必有“數(shù)據(jù)路由”的概念，哪個(gè)數(shù)據(jù)訪問哪個(gè)庫。
路由規(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í)設(shè)計(jì)些什么東西呢？至少要考慮以下四點(diǎn)：
（1）如何保證數(shù)據(jù)可用性
（2）如何提高數(shù)據(jù)庫讀性能（大部分應(yīng)用讀多寫少，讀會(huì)先成為瓶頸）
（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ù)的冗余，會(huì)帶來一個(gè)副作用=>引發(fā)一致性問題（先不說一致性問題，先說可用性）
如何保證數(shù)據(jù)庫“讀”高可用？
冗余讀庫
冗余讀庫帶來的副作用？讀寫有延時(shí)，可能不一致
上面這個(gè)圖是很多互聯(lián)網(wǎng)公司mysql的架構(gòu)，寫仍然是單點(diǎn)，不能保證寫高可用。
如何保證數(shù)據(jù)庫“寫”高可用？
冗余寫庫
采用雙主互備的方式，可以冗余寫庫
帶來的副作用？雙寫同步，數(shù)據(jù)可能沖突（例如“自增id”同步?jīng)_突）,如何解決同步?jīng)_突，有兩種常見解決方案：
（1）兩個(gè)寫庫使用不同的初始值，相同的步長來增加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)主從用”的方式：
仍是雙主，但只有一個(gè)主提供服務(wù)（讀+寫），另一個(gè)主是“shadow-master”，只用來保證高可用，平時(shí)不提供服務(wù)。
master掛了，shadow-master頂上（vip漂移，對業(yè)務(wù)層透明，不需要人工介入）
這種方式的好處：
1）讀寫沒有延時(shí)
2）讀寫高可用
不足：
1）不能通過加從庫的方式擴(kuò)展讀性能
2）資源利用率為50%，一臺冗余主沒有提供服務(wù)
那如何提高讀性能呢？進(jìn)入第二個(gè)話題，如何提供讀性能。
2.2如何擴(kuò)展讀性能？
提高讀性能的方式大致有三種，第一種是建立索引。這種方式不展開，要提到的一點(diǎn)是，不同的庫可以建立不同的索引。
寫庫不建立索引；
線上讀庫建立線上訪問索引，例如uid；
線下讀庫建立線下訪問索引，例如time；
第二種擴(kuò)充讀性能的方式是，增加從庫，這種方法大家用的比較多，但是，存在兩個(gè)缺點(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），一定會(huì)引發(fā)一致性問題。
2.3如何保證一致性？
主從數(shù)據(jù)庫的一致性，通常有兩種解決方案：
（1）中間件
如果某一個(gè)key有寫操作，在不一致時(shí)間窗口內(nèi)，中間件會(huì)將這個(gè)key的讀操作也路由到主庫上。
這個(gè)方案的缺點(diǎn)是，數(shù)據(jù)庫中間件的門檻較高（百度，騰訊，阿里，360等一些公司有，當(dāng)然58也有）
（2）強(qiáng)制讀主
58的“雙主當(dāng)主從用”的架構(gòu)，不存在主從不一致的問題。
第二類不一致，是db與緩存間的不一致
常見的緩存架構(gòu)如上，此時(shí)寫操作的順序是：
（1）淘汰cache
（2）寫數(shù)據(jù)庫
讀操作的順序是：
（1）讀cache，如果cache hit則返回
（2）如果cache miss，則讀從庫
（3）讀從庫后，將數(shù)據(jù)放回cache
在一些異常時(shí)序情況下，有可能從【從庫讀到舊數(shù)據(jù)（同步還沒有完成），舊數(shù)據(jù)入cache后】，數(shù)據(jù)會(huì)長期不一致。
解決辦法是“緩存雙淘汰”，寫操作時(shí)序升級為：
（1）淘汰cache
（2）寫數(shù)據(jù)庫
（3）在經(jīng)驗(yàn)“主從同步延時(shí)窗口時(shí)間”后，再次發(fā)起一個(gè)異步淘汰cache的請求
這樣，即使有臟數(shù)據(jù)如cache，一個(gè)小的時(shí)間窗口之后，臟數(shù)據(jù)還是會(huì)被淘汰。帶來的代價(jià)是，多引入一次讀miss（成本可以忽略）。
除此之外，58同城的最佳實(shí)踐之一是：建議為所有cache中的item設(shè)置一個(gè)超時(shí)時(shí)間。
說完一致性，最后一個(gè)話題是擴(kuò)展性。
2.4如何提高數(shù)據(jù)庫的擴(kuò)展性？
原來用hash的方式路由，分為2個(gè)庫，數(shù)據(jù)量還是太大，要分為3個(gè)庫，勢必需要進(jìn)行數(shù)據(jù)遷移，58同城有一個(gè)很帥氣的“數(shù)據(jù)庫秒級擴(kuò)容”方案。
如何秒級擴(kuò)容？
首先，我們不做2庫變3庫的擴(kuò)容，我們做2庫變4庫（庫加倍）的擴(kuò)容（未來4->8->16）
服務(wù)+數(shù)據(jù)庫是一套（省去了緩存）
數(shù)據(jù)庫采用“雙主”的模式。
擴(kuò)容步驟：
第一步，將一個(gè)主庫提升
第二步，修改配置，2庫變4庫（原來MOD2，現(xiàn)在配置修改后MOD4）
擴(kuò)容完成
原MOD2為偶的部分，現(xiàn)在會(huì)MOD4余0或者2
原MOD2為奇的部分，現(xiàn)在會(huì)MOD4余1或者3
數(shù)據(jù)不需要遷移，同時(shí)，雙主互相同步，一遍是余0，一邊余2，兩邊數(shù)據(jù)同步也不會(huì)沖突，秒級完成擴(kuò)容！
最后，要做一些收尾工作：
（1）將舊的雙主同步解除
（2）增加新的雙主（雙主是保證可用性的，shadow-master平時(shí)不提供服務(wù)）
（3）刪除多余的數(shù)據(jù)（余0的主，可以將余2的數(shù)據(jù)刪除掉）
這樣，秒級別內(nèi)，我們就完成了2庫變4庫的擴(kuò)展。
OK，今天主要分享了58同城，數(shù)據(jù)庫軟件架構(gòu)上：
（1）如何保證數(shù)據(jù)可用性
（2）如何提高數(shù)據(jù)庫讀性能
（3）如何保證數(shù)據(jù)一致性
（4）如何進(jìn)行秒級擴(kuò)容
