一、數(shù)據(jù)庫架構(gòu)原則

高可用

高性能

可擴展

一致性

二、常見的架構(gòu)方案

方案一：主備架構(gòu)，只有主庫提供讀寫服務(wù)，備庫冗余作故障轉(zhuǎn)移用

jdbc:mysql://vip:3306/xxdb

高可用分析：高可用，主庫掛了，keepalive(只是一種工具)會自動切換到備庫。這個過程對業(yè)務(wù)層是透明的，無需修改代碼或配置。

高性能分析：讀寫都操作主庫，很容易產(chǎn)生瓶頸。大部分互聯(lián)網(wǎng)應(yīng)用讀多寫少，讀會先成為瓶頸，進而影響寫性能。另外，備庫只是單純的備份，資源利用率50%，這點方案二可解決。

一致性分析：讀寫都操作主庫，不存在數(shù)據(jù)一致性問題。

擴展性分析：無法通過加從庫來擴展讀性能。

可落地分析：兩點影響落地使用。第一，性能一般，這點可以通過建立高效的索引和引入緩存來增加讀性能，進而提高性能。這也是通用的方案。第二，擴展性差，這點可以通過分庫分表來擴展。

方案二：雙主架構(gòu)，兩個主庫同時提供服務(wù)，負載均衡

jdbc:mysql://vip:3306/xxdb

高可用分析：高可用，一個主庫掛了，不影響另一臺主庫提供服務(wù)。這個過程對業(yè)務(wù)層是透明的，無需修改代碼或配置。

高性能分析：讀寫性能相比于方案一都得到提升，提升一倍。

一致性分析：存在數(shù)據(jù)一致性問題。請看，一致性解決方案。

擴展性分析：當(dāng)然可以擴展成三主循環(huán)，但不建議(會多一層數(shù)據(jù)同步，這樣同步的時間會更長)。如果非得在數(shù)據(jù)庫架構(gòu)層面擴展的話，擴展為方案四。

可落地分析：兩點影響落地使用。第一，數(shù)據(jù)一致性問題，一致性解決方案可解決問題。第二，主鍵沖突問題，ID統(tǒng)一地由分布式ID生成服務(wù)來生成可解決問題。

方案三：主從架構(gòu)，一主多從，讀寫分離

jdbc:mysql://master-ip:3306/xxdb

jdbc:mysql://slave1-ip:3306/xxdb

jdbc:mysql://slave2-ip:3306/xxdb

高可用分析：主庫單點，從庫高可用。一旦主庫掛了，寫服務(wù)也就無法提供。

高性能分析：大部分互聯(lián)網(wǎng)應(yīng)用讀多寫少，讀會先成為瓶頸，進而影響整體性能。讀的性能提高了，整體性能也提高了。另外，主庫可以不用索引，線上從庫和線下從庫也可以建立不同的索引(線上從庫如果有多個還是要建立相同的索引，不然得不償失；線下從庫是平時開發(fā)人員排查線上問題時查的庫，可以建更多的索引)。

一致性分析：存在數(shù)據(jù)一致性問題。請看，一致性解決方案。

擴展性分析：可以通過加從庫來擴展讀性能，進而提高整體性能。(帶來的問題是，從庫越多需要從主庫拉取binlog日志的端就越多，進而影響主庫的性能，并且數(shù)據(jù)同步完成的時間也會更長。建議不要分多層，且一臺主庫一般掛3-5臺從庫吧。一般配置的mysql，并發(fā)最好控制在2000/s，掛5臺的話，整體基本能支撐1w+/s的并發(fā)，再加上緩存和二八定律，基本能支撐小10w/s的并發(fā)，很高了。如果還不能滿足需求，那還是選擇去分庫吧。)

可落地分析：兩點影響落地使用。第一，數(shù)據(jù)一致性問題，一致性解決方案可解決問題。第二，主庫單點問題，暫時沒想到很好的解決方案(這點評論里給了一種方案，可參考)。

注：思考一個問題，一臺從庫掛了會怎樣？讀寫分離之讀的負載均衡策略怎么容錯？

方案四：雙主+主從架構(gòu)，看似完美的方案

jdbc:mysql://vip:3306/xxdb

jdbc:mysql://slave1-ip:3306/xxdb

jdbc:mysql://slave2-ip:3306/xxdb

高可用分析：高可用。

高性能分析：高性能。

一致性分析：存在數(shù)據(jù)一致性問題。請看，一致性解決方案。

擴展性分析：可以通過加從庫來擴展讀性能，進而提高整體性能。(帶來的問題同方案二)

可落地分析：同方案二，但數(shù)據(jù)同步又多了一層，數(shù)據(jù)延遲更嚴重。

三、一致性解決方案

第一類：主庫和從庫一致性解決方案

注：圖中圈出的是數(shù)據(jù)同步的地方，數(shù)據(jù)同步(MySQL主從復(fù)制，簡單來說就是從庫從主庫拉取binlog日志，再執(zhí)行一遍，想深入了解可以去查閱“MySQL主從復(fù)制原理”相關(guān)資料)是需要時間的，這個同步時間內(nèi)主庫和從庫的數(shù)據(jù)會存在不一致的情況。如果同步過程中有讀請求，那么讀到的就是從庫中的老數(shù)據(jù)。如下圖。

既然知道了數(shù)據(jù)不一致性產(chǎn)生的原因，有下面幾個解決方案供參考：

直接忽略，如果業(yè)務(wù)允許延時存在，那么就不去管它。

強制讀主，采用主備架構(gòu)方案，或者代碼指定讀主庫(一般不建議，這樣就失去了讀寫分離的意義)，讀寫都走主庫。

選擇讀主，寫操作時根據(jù)庫+表+業(yè)務(wù)特征生成一個key放到Cache里并設(shè)置超時時間(大于等于主從數(shù)據(jù)同步時間)。讀請求時，同樣的方式生成key先去查Cache，再判斷是否命中。若命中，則讀主庫，否則讀從庫。代價是多了一次緩存讀寫，基本可以忽略。

數(shù)據(jù)庫中間件，引入開源(mycat等)或自研的數(shù)據(jù)庫中間層。個人理解，思路同選擇讀主。數(shù)據(jù)庫中間件的成本比較高，并且還多引入了一層。

第二類：DB和緩存一致性解決方案

先來看一下常用的緩存使用方式：

第一步：淘汰緩存；

第二步：寫入數(shù)據(jù)庫；

第三步：讀取緩存？返回：讀取數(shù)據(jù)庫；

第四步：讀取數(shù)據(jù)庫后寫入緩存。

一般來說，并發(fā)量不是特別大的話，上面的方式就可以。但是如果是高并發(fā)量的情況下，當(dāng)寫入時，你淘汰了緩存，但是還沒寫入數(shù)據(jù)庫時或者主從延時，就有一個讀請求完成了，此時緩存中就會緩存舊的數(shù)據(jù)。此時可以，寫庫完成時，等一會(根據(jù)業(yè)務(wù)場景評估)再刪除一次緩存，這樣緩存舊數(shù)據(jù)的概率又低了，不過這樣一來數(shù)據(jù)庫的壓力就會有相應(yīng)的增加，并且響應(yīng)時間會增加。其實，要想保證數(shù)據(jù)庫和緩存嚴格的一致性很難，甚至要付出很高的代價。網(wǎng)上還個方案，就是用本地內(nèi)存隊列來控制讀請求和寫請求串行化，利弊都有，感興趣可深入研究：高并發(fā)場景下，如何保證緩存和數(shù)據(jù)庫雙寫的一致性。另外，思考一下是不是能用基于臨時順序節(jié)點的Zookeeper分布式鎖(用兩個鎖，一個讀鎖，一個寫鎖，當(dāng)排在寫鎖后面的第一個讀鎖被通知時，讀操作完成后，批量刪除后面連續(xù)的讀鎖，注意不要引發(fā)羊群效應(yīng) -> 主備架構(gòu)時)？

注：設(shè)置緩存時，一定要加上失效時間！

四、個人的一些見解

1、架構(gòu)演變

架構(gòu)演變一：方案一 -> 方案一+分庫分表；

架構(gòu)演變二：方案一 -> 方案三 -> 方案三+分庫分表

架構(gòu)演變?nèi)?#xff1a;方案一 -> 方案二 -> 方案二+分庫分表

注：方案四一般不用。

2、個人見解

加緩存和索引是通用的提升數(shù)據(jù)庫性能的方式；

分庫分表帶來的好處是巨大的，但同樣也會帶來一些問題，詳見MySQL數(shù)據(jù)庫之互聯(lián)網(wǎng)常用分庫分表方案。

不管是主備+分庫分表還是主從+讀寫分離+分庫分表，都要考慮具體的業(yè)務(wù)場景。一般大部分的數(shù)據(jù)庫架構(gòu)還是采用方案一和方案一+分庫分表，典型的讀多寫少的場景用方案三+讀寫分離+分庫分表。另外，阿里云提供的數(shù)據(jù)庫云服務(wù)也都是主備方案，要想主從+讀寫分離需要二次架構(gòu)。

記住一句話：不考慮業(yè)務(wù)場景的架構(gòu)都是耍流氓。

總結(jié)

以上是生活随笔為你收集整理的mysql数据库架构_MySQL数据库之互联网常用架构方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。