數據庫之互聯網經常使用架構方案

1、數據庫架構原則

• 高可用

• 高性能

• 一致性

• 擴展性

2、常見的架構方案

方案一：主備架構，只有主庫提供讀寫服務，備庫冗餘做故障轉移用

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.可落地分析： 同方案二，但數據同步又多了一層，數據延遲更嚴重。

3、一致性解決方案

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

注：圖中圈出的是數據同步的地方，數據同步（從庫從主庫拉取binlog日誌，再執行一遍）是須要時間的，這個同步時間內主庫和從庫的數據會存在不一致的狀況。若是同步過程當中有讀請求，那麼讀到的就是從庫中的老數據。以下圖。

既然知道了數據不一致性產生的緣由，有下面幾個解決方案供參考：

1.直接忽略，若是業務容許延時存在，那麼就不去管它。

2.強制讀主，採用主備架構方案，讀寫都走主庫。用緩存來擴展數據庫讀性能 。有一點須要知道：若是緩存掛了，可能會產生雪崩現象，不過通常分佈式緩存都是高可用的。

3.選擇讀主，寫操做時根據庫+表+業務特徵生成一個key放到Cache裏並設置超時時間（大於等於主從數據同步時間）。讀請求時，一樣的方式生成key先去查Cache，再判斷是否命中。若命中，則讀主庫，不然讀從庫。代價是多了一次緩存讀寫，基本能夠忽略。

4.半同步複製，等主從同步完成，寫請求才返回。就是你們常說的「半同步複製」semi-sync。這能夠利用數據庫原生功能，實現比較簡單。代價是寫請求時延增加，吞吐量下降。

5.數據庫中間件，引入開源（sharding-jdbc等）或自研的數據庫中間層。我的理解，思路同選擇讀主。數據庫中間件的成本比較高，而且還多引入了一層。

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

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

第一步：淘汰緩存；

第二步：寫入數據庫；

第三步：讀取緩存？返回：讀取數據庫；

第四步：讀取數據庫後寫入緩存。

注：若是按照這種方式，圖一，不會產生DB和緩存不一致問題；圖二，會產生DB和緩存不一致問題，即4.read先於3.sync執行。若是不作處理，緩存裏的數據可能一直是髒數據。解決方式以下：

注：設置緩存時，必定要加上失效時間，以防延時淘汰緩存失敗的狀況！

4、我的的一些看法

一、架構演變

• 架構演變一：方案一 -> 方案一+分庫分表 -> 方案二+分庫分表 -> 方案四+分庫分表；
• 架構演變二：方案一 -> 方案一+分庫分表 -> 方案三+分庫分表 -> 方案四+分庫分表；
• 架構演變三：方案一 -> 方案二 -> 方案四 -> 方案四+分庫分表；
• 架構演變四：方案一 -> 方案三 -> 方案四 -> 方案四+分庫分表；

二、我的看法

加緩存和索引是通用的提高數據庫性能的方式；

分庫分錶帶來的好處是巨大的，但一樣也會帶來一些問題，詳見數據庫之分庫分表-垂直？水平？

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

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

來源: sina.lt/gbZQ
整編:李浩東的博客

推薦閱讀:
SpringBoot 2.x ShardingSphere分庫分表實戰
SpringBoot 2.x ShardingSphere讀寫分離實戰
Spring Boot 實戰 數據庫千萬級分庫分表和讀寫分離實戰