MySQL資料庫之網際網路常用架構方案(全)

資料和雲發表於2019-12-19

作者:尜尜人物


本文包含資料庫架構原則、常見的四種架構方案、兩種一致性解決方案、以及作者個人的一些見解。


一、資料庫架構原則



1、高可用

2、高效能

3、一致性

4、擴充套件性


二、常見的架構方案



方案一:主備架構,只有主庫提供讀寫服務,備庫冗餘作故障轉移用


 jdbc:mysql://vip:3306/xxdb


  1. 高可用分析: 高可用,主庫掛了,keepalive(只是一種工具)會自動切換到備庫。這個過程對業務層是透明的,無需修改程式碼或配置。

  2. 高效能分析: 讀寫都操作主庫,很容易產生瓶頸。大部分網際網路應用讀多寫少,讀會先成為瓶頸,進而影響寫效能。另外,備庫只是單純的備份,資源利用率50%,這點方案二可解決。

  3. 一致性分析: 讀寫都操作主庫,不存在資料一致性問題。

  4. 擴充套件性分析: 無法通過加從庫來擴充套件讀效能,進而提高整體效能。

  5. 可落地分析: 兩點影響落地使用。第一,效能一般,這點可以通過建立高效的索引和引入快取來增加讀效能,進而提高效能。這也是通用的方案。第二,擴充套件性差,這點可以通過分庫分表來擴充套件。


方案二:雙主架構,兩個主庫同時提供服務,負載均衡


 jdbc:mysql://vip:3306/xxdb


  1. 高可用分析: 高可用,一個主庫掛了,不影響另一臺主庫提供服務。這個過程對業務層是透明的,無需修改程式碼或配置。

  2. 高效能分析: 讀寫效能相比於方案一都得到提升,提升一倍。

  3. 一致性分析: 存在資料一致性問題。請看,一致性解決方案。

  4. 擴充套件性分析: 當然可以擴充套件成三主迴圈,但筆者不建議(會多一層資料同步,這樣同步的時間會更長)。如果非得在資料庫架構層面擴充套件的話,擴充套件為方案四。

  5. 可落地分析: 兩點影響落地使用。第一,資料一致性問題,一致性解決方案可解決問題。第二,主鍵衝突問題,ID統一地由分散式ID生成服務來生成可解決問題。


方案三:主從架構,一主多從,讀寫分離


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

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

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


  1. 高可用分析: 主庫單點,從庫高可用。一旦主庫掛了,寫服務也就無法提供。

  2. 高效能分析: 大部分網際網路應用讀多寫少,讀會先成為瓶頸,進而影響整體效能。讀的效能提高了,整體效能也提高了。另外,主庫可以不用索引,線上從庫和線下從庫也可以建立不同的索引(線上從庫如果有多個還是要建立相同的索引,不然得不償失;線下從庫是平時開發人員排查線上問題時查的庫,可以建更多的索引)。

  3. 一致性分析: 存在資料一致性問題。請看,一致性解決方案。

  4. 擴充套件性分析: 可以通過加從庫來擴充套件讀效能,進而提高整體效能。(帶來的問題是,從庫越多需要從主庫拉取binlog日誌的端就越多,進而影響主庫的效能,並且資料同步完成的時間也會更長)

  5. 可落地分析: 兩點影響落地使用。第一,資料一致性問題,一致性解決方案可解決問題。第二,主庫單點問題,筆者暫時沒想到很好的解決方案。

注:思考一個問題,一臺從庫掛了會怎樣?讀寫分離之讀的負載均衡策略怎麼容錯?


方案四:雙主+主從架構,看似完美的方案


 jdbc:mysql://vip:3306/xxdb

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

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


  1. 高可用分析: 高可用。

  2. 高效能分析: 高效能。

  3. 一致性分析: 存在資料一致性問題。請看,一致性解決方案。

  4. 擴充套件性分析:可以通過加從庫來擴充套件讀效能,進而提高整體效能。(帶來的問題同方案二)

  5. 可落地分析 :同方案二,但資料同步又多了一層,資料延遲更嚴重。


三、一致性解決方案



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



注: 圖中圈出的是資料同步的地方,資料同步(從庫從主庫拉取binlog日誌,再執行一遍)是需要時間的,這個同步時間內主庫和從庫的資料會存在不一致的情況。如果同步過程中有讀請求,那麼讀到的就是從庫中的老資料。如下圖。



既然知道了資料不一致性產生的原因,有下面幾個解決方案供參考:


1、直接忽略,如果業務允許延時存在,那麼就不去管它。


2、強制讀主,採用主備架構方案,讀寫都走主庫。用快取來擴充套件資料庫讀效能 。有一點需要知道:如果快取掛了,可能會產生雪崩現象,不過一般分散式快取都是高可用的。



3、選擇讀主,寫操作時根據庫+表+業務特徵生成一個key放到Cache裡並設定超時時間(大於等於主從資料同步時間)。讀請求時,同樣的方式生成key先去查Cache,再判斷是否命中。若命中,則讀主庫,否則讀從庫。代價是多了一次快取讀寫,基本可以忽略。



4、半同步複製,等主從同步完成,寫請求才返回。就是大家常說的“半同步複製”semi-sync。這可以利用資料庫原生功能,實現比較簡單。代價是寫請求時延增長,吞吐量降低。


5、資料庫中介軟體,引入開源(mycat等)或自研的資料庫中間層。個人理解,思路同選擇讀主。資料庫中介軟體的成本比較高,並且還多引入了一層。



第二類:DB和快取一致性解決方案



先來看一下常用的快取使用方式:


第一步:淘汰快取;

第二步:寫入資料庫;

第三步:讀取快取?返回:讀取資料庫;

第四步:讀取資料庫後寫入快取。


注:如果按照這種方式,圖一,不會產生DB和快取不一致問題;圖二,會產生DB和快取不一致問題,即4.read先於3.sync執行。如果不做處理,快取裡的資料可能一直是髒資料。解決方式如下:



注:設定快取時,一定要加上失效時間,以防延時淘汰快取失敗的情況!


四、個人的一些見解



1、架構演變


1、架構演變一:方案一 -> 方案一+分庫分表 -> 方案二+分庫分表 -> 方案四+分庫分表;

2、架構演變二:方案一 -> 方案一+分庫分表 -> 方案三+分庫分表 -> 方案四+分庫分表;

3、架構演變三:方案一 -> 方案二 -> 方案四 -> 方案四+分庫分表;

4、架構演變四:方案一 -> 方案三 -> 方案四 -> 方案四+分庫分表;


2、個人見解


1、加快取和索引是通用的提升資料庫效能的方式;

2、分庫分錶帶來的好處是巨大的,但同樣也會帶來一些問題,詳見 MySQL資料庫之網際網路常用分庫分表方案 https://www.cnblogs.com/littlecharacter/p/9342129.html

3、不管是主備+分庫分表還是主從+讀寫分離+分庫分表,都要考慮具體的業務場景。某8到家發展四年,絕大部分的資料庫架構還是採用方案一和方案一+分庫分表,只有極少部分用方案三+讀寫分離+分庫分表。另外,阿里雲提供的資料庫雲服務也都是主備方案,要想主從+讀寫分離需要二次架構。

4、記住一句話:不考慮業務場景的架構都是耍流氓。


來源:cnblogs.com/littlecharacter/p/9084291.html



來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31556440/viewspace-2669409/,如需轉載,請註明出處,否則將追究法律責任。

相關文章