在互聯(lián)網項目中，當業(yè)務規(guī)模越來越大，數據也越來越多，隨之而來的就是數據庫壓力會越來越大。

我們可能會采取各種方式去優(yōu)化，比如之前文章提到的緩存方案，SQL 優(yōu)化等等，除了這些方式以外，這里再分享幾個針對數據庫優(yōu)化的常規(guī)手段：「數據讀寫分離」與「數據庫 Sharding」。這兩點基本上是大中型互聯(lián)網項目中應用的非常普遍的方案了。

下面我們來詳細看一看，

一、從讀寫分離到 CQRS

 

 

(圖片來源阿里云)

由于互聯(lián)網業(yè)務場景，大多數是讀多寫少，因此進行數據庫的讀寫分離是一件非常簡單且有效率的方案。

讀寫分離簡單點來說就是把對數據的讀操作和寫操作進行分開來，讓這兩種操作去訪問不同的數據庫，這樣的話，就可以減輕數據庫的壓力了。

例如上圖中，數據庫會有一個「主實例」，這個主要用來提供寫操作的(偶爾也會承擔一點讀操作)，除了「主實例」以外，還會有多個「從實例」(在圖中顯示的是 只讀實例)，「從實例」的功能只是用來承擔讀操作的。

那上面就出現(xiàn)了多個數據庫了，在多個數據庫之間的數據是怎么保證一致性的呢?

其實，我們常用的數據庫就自帶這類同步功能，比如 Mysql，它自己有一個 master-slave 功能，可以實現(xiàn)主庫與從庫數據的自動同步，是基于二進制日志復制來實現(xiàn)的。在主庫進行的寫操作，會形成二進制日志，然后 Mysql 會把這個日志異步的同步到從庫上，從庫再自動執(zhí)行一遍這個二進制日志，那么數據就跟主庫一致了。

除了 Mysql 以外，像 Oracle 等商業(yè)數據庫都有類似的功能，甚至是網絡上還有很多開源的第三方數據同步工具，也有很多成熟好用的。

好了，「主實例」與「從實例」之間的數據同步問題解決了，那現(xiàn)在還有一個問題就是，項目中是怎樣讓 寫請求 去訪問「主實例」，讓 讀請求 去訪問「從實例」的，這個路由規(guī)則是怎么實現(xiàn)的呢?

常規(guī)的有 2 種方式：

使用編碼方式

這個方式主要是靠開發(fā)同學在編碼的時候，根據讀寫不同的操作需求，去調用不同的數據源。例如在數據操作層(DAO 層)將讀數據與寫數據分開為兩個方法(函數)，然后為這兩個方法分別指定不同的數據庫即可。

但是這種方式有點硬編碼的味道了，而且對開發(fā)同學而言還得額外關注這個事情，多了一個編碼成本且容易不小心忽略掉。

使用中間件

這種方式就是在后端數據庫的前面，前置一個 數據庫代理服務，如下圖的：MySQL-Proxy 是 Mysql 提供的一個中間件，用于實現(xiàn)讀寫分離請求，但這個組件實際用的人不多，我們可以選擇其它的一些開源的組件替代，例如：Mycat、ProxySQL 等等，但大致的原理比較類似，通過這個圖很容易理解這個模式。

 

 

好了，基礎的讀寫分離就講完了，但感覺這個方式雖然實用是實用，就是不怎么有逼格。

OK，想要有逼格是吧，滿足你，那我們就來聊一聊另一個有逼格的讀寫分離概念: 「 CQRS 」

CQRS：Command Query Responsibility Segregation

命令(增刪改)和查詢的責任分離

 

 

我們還是先看圖，通過上圖可以簡單的理解一下 CQRS

CQRS 重點強調的就是 Query(讀) 和 Command(寫)的分離，在業(yè)務上將職責分離清晰，Command 主要做業(yè)務邏輯的執(zhí)行，Query 來負責數據查詢和展示。同時 這兩種操作是基于不同的數據源，甚至是一個是數據庫，另外一個是 NoSQL 都可以，Query 去查詢的數據源可以直接按照領域模型進行存儲，而并不是按照數據模型去存儲，這樣查詢出來就立即可以展示，而不用轉換，且查詢效率高。

其實 CQRS 是由鼎鼎大名的 Martin Fowler 提出，搞計算機的應該都認識。想要更深入的去學習 CQRS，可以翻看 Martin Fowler 公開的資料。

二、Sharding(分庫分表)

上面講完了數據庫的讀寫分離，現(xiàn)在我們來聊一下數據庫的 Sharding。

隨著數據庫里的數據越來越大，單表查詢的性能已經不能滿足業(yè)務要求了，這個時候就需要進行分表處理了，將大表拆分為若干個小表，不同的分表中數據也不一樣，這樣可以分散查詢壓力，提高處理效率。

然而，當表越來越多，所有的數據都在一個數據庫上時，網絡 IO 以及文件 IO 也都會集中在一個數據庫上，可能會超過單臺服務器的容量， CPU、內存、文件 IO、網絡 IO 都會成為系統(tǒng)的瓶頸，QPS/TPS 也會超過單數據庫實例的處理極限。那么這個時候就需要對數據庫進行分片處理。

因為分表和分庫的思路類似，因此下面統(tǒng)一來聊技術方案。

其實分庫分表只是我們通俗的便于理解的說話，正確的描述應該是：數據分片

數據的分片主要有 2 種模式：

• 垂直拆分

• 水平拆分

兩種拆分應用的場景是不同的：

垂直拆分，是指按照業(yè)務模塊進行拆分。簡單來講，就是把業(yè)務緊密的模塊的字段 / 表放在一起，放在同一個數據庫或者服務器上。將不同業(yè)務的字段 / 表進行獨立，拆到不同的數據庫或者服務器上。比如一個游戲系統(tǒng)中，可以將玩家基本信息與道具公會等信息進行拆分。

如圖示例：

 

 

(圖片來源網絡)

水平拆分，是指純粹的按照某種數據規(guī)則 / 格式進行拆分。例如 按照數據 ID 的哈希散列拆分、按照數據的日期拆分、按照某種范圍拆分等等。水平拆分需要注意的是，隨著數據動態(tài)的變化，分片數量可能需要隨之動態(tài)調整，另外就是水平分片是沒有考慮業(yè)務特征的，因此在進行業(yè)務匯總查詢或者分片中事物處理的時候就比較麻煩一些。

如圖示例：

 

 

另外，在實際應用中，兩種拆分模式一般會結合在一起使用，效果更佳。

標簽： Mysql 服務器 互聯(lián)網 互聯(lián)網業(yè)務 數據庫 網絡

版權申明：本站文章部分自網絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。