歡迎光臨
每天分享高質量文章

資料庫之架構:主備+分庫?主從+讀寫分離?

作者:尜尜人物

連結:https://www.cnblogs.com/littlecharacter/p/9084291.html

一、資料庫架構原則

  1. 高可用

  2. 高效能

  3. 一致性

  4. 擴充套件性

二、常見的架構方案

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

  1. jdbc:mysql://vip:3306/xxdb

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

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

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

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

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

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

  1. jdbc:mysql://vip:3306/xxdb

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. jdbc:mysql://vip:3306/xxdb

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

  3. 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、分庫分錶帶來的好處是巨大的,但同樣也會帶來一些問題,詳見前日推文。

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

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

已同步到看一看
贊(0)

分享創造快樂