如何在MySQL資料庫中進行網際網路常用架構的搭建？

這篇文章主要跟大家介紹的是如何在MySQL資料庫中進行網際網路常用架構的搭建，小杜相信很多沒有經驗的小夥伴都對此束手無策吧，為此，摩杜雲小杜整理了一下並分享給大家做個參考，由於內容質量高且有閱讀性，感興趣的朋友不妨進來看看。

在MySQL資料庫中進行網際網路常用架構的搭建的操作方法：

一、資料庫架構原則

1.高可用——2.高效能——3.一致性——4.擴充套件性

二、常見的架構方法

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

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

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

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

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

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

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

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

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

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

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

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

方案三：主從架構，一主多從，讀寫分離

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

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

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

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

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

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

方案四：雙主+主從架構，看似完美的方案

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、架構演變

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

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

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

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

2、個人見解

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

2.分庫分錶帶來的好處是巨大的，但同樣也會帶來一些問題。

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

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

好了，關於如何在MySQL資料庫中進行網際網路常用架構的搭建的內容介紹就到此結束，相信大家看完之後都知道怎麼在MySQL資料庫中進行網際網路常用架構的搭建了吧，如果還想了解更多行業相關知識，可以關注摩杜雲行業資訊頻道，更多高質量的文章等著你來看，感謝各位的閱讀!