本文以MySQL數(shù)據(jù)庫(kù)為例說明。
一、數(shù)據(jù)庫(kù)架構(gòu)原則有以下幾種：
1、高可用
2、高性能
3、一致性
4、擴(kuò)展性
二、常見的架構(gòu)方案：
- 方案一：主備架構(gòu)，只有主庫(kù)提供讀寫服務(wù)，備庫(kù)冗余作故障轉(zhuǎn)移用
- 方案二：雙主架構(gòu)，兩個(gè)主庫(kù)同時(shí)提供服務(wù)，負(fù)載均衡
- 方案三：主從架構(gòu)，一主多從，讀寫分離
- 方案四：雙主+主從架構(gòu)，看似完美的方案
三、弊端解決方案
任何方案都有弊端，有了弊端就要有應(yīng)對(duì)方案。
- 第一類：主庫(kù)和從庫(kù)一致性解決方案
下面是解決數(shù)據(jù)不一致性產(chǎn)生的原因：
1、直接忽略，如果業(yè)務(wù)允許延時(shí)存在，那么就不去管它。
2、強(qiáng)制讀主，采用主備架構(gòu)方案，讀寫都走主庫(kù)。用緩存來(lái)擴(kuò)展數(shù)據(jù)庫(kù)讀性能 。有一點(diǎn)需要知道：如果緩存掛了，可能會(huì)產(chǎn)生雪崩現(xiàn)象，不過一般分布式緩存都是高可用的。
3、選擇讀主，寫操作時(shí)根據(jù)庫(kù)+表+業(yè)務(wù)特征生成一個(gè)key放到Cache里并設(shè)置超時(shí)時(shí)間（大于等于主從數(shù)據(jù)同步時(shí)間）。讀請(qǐng)求時(shí)，同樣的方式生成key先去查Cache，再判斷是否命中。若命中，則讀主庫(kù)，否則讀從庫(kù)。代價(jià)是多了一次緩存讀寫，基本可以忽略。
4、半同步復(fù)制，等主從同步完成，寫請(qǐng)求才返回。就是大家常說的“半同步復(fù)制”semi-sync。這可以利用數(shù)據(jù)庫(kù)原生功能，實(shí)現(xiàn)比較簡(jiǎn)單。代價(jià)是寫請(qǐng)求時(shí)延增長(zhǎng)，吞吐量降低。
5、數(shù)據(jù)庫(kù)中間件，引入開源（mycat等）或自研的數(shù)據(jù)庫(kù)中間層。個(gè)人理解，思路同選擇讀主。數(shù)據(jù)庫(kù)中間件的成本比較高，并且還多引入了一層。
- 第二類：DB和緩存一致性解決方案
下面是常用的緩存使用方式：
第一步：淘汰緩存；
第二步：寫入數(shù)據(jù)庫(kù)；
第三步：讀取緩存？返回：讀取數(shù)據(jù)庫(kù)；
第四步：讀取數(shù)據(jù)庫(kù)后寫入緩存。
四、總結(jié)
1、架構(gòu)演變歷史
- 架構(gòu)演變一：方案一 -> 方案一+分庫(kù)分表 -> 方案二+分庫(kù)分表 -> 方案四+分庫(kù)分表；
- 架構(gòu)演變二：方案一 -> 方案一+分庫(kù)分表 -> 方案三+分庫(kù)分表 -> 方案四+分庫(kù)分表；
- 架構(gòu)演變?nèi)悍桨敢?-> 方案二 -> 方案四 -> 方案四+分庫(kù)分表；
- 架構(gòu)演變四：方案一 -> 方案三 -> 方案四 -> 方案四+分庫(kù)分表；
2、個(gè)人見解
- 加緩存和索引是通用的提升數(shù)據(jù)庫(kù)性能的方式；
- 分庫(kù)分表帶來(lái)的好處是巨大的，但同樣也會(huì)帶來(lái)一些問題。
- 不管是主備+分庫(kù)分表還是主從+讀寫分離+分庫(kù)分表，都要考慮具體的業(yè)務(wù)場(chǎng)景。
有報(bào)考軟件設(shè)計(jì)師而且想快速通過的朋友請(qǐng)私信我，給你傳授經(jīng)驗(yàn)。
