圖文解釋 讀寫分離、垂直拆分、水平拆分、分庫分表

1. 前言

相信你常常被 讀寫分離、垂直拆分、水平拆分、分庫分表 這幾個名詞搞得很懵逼。我有時候也很懵逼，那麼今天就來把這幾個數據庫經常使用術語搞清楚，同時也記錄一下。

2. 讀寫分離

這個相對比較好理解一些，就是將數據庫分爲主從庫，一個主庫（Master）用於寫數據，多個從庫（Slaver）進行輪詢讀取數據的過程，主從庫之間經過某種通信機制進行數據的同步，是一種常見的數據庫架構。下面這張圖就展現了 「一主二從」 的結構：

2.1 爲何要讀寫分離

大多數互聯網數據操做每每都是讀多寫少，隨着數據的增加，數據庫的 「讀」 會首先成爲瓶頸。若是咱們但願能線性地提高數據庫的讀性能和寫性能，就須要讓讀寫儘量的不相互影響，各自爲政。在使用讀寫分離以前咱們應該考慮使用緩存能不能解決問題。而後再考慮對數據庫按照 「讀」 和 「寫」 進行分組。讀寫分離意味着將一體的結構的進行分散，在數據量大、高併發的情景中要考慮如下這些問題

1. 如何保證 Master 的高可用，故障轉移，熔斷限流等。
2. 讀寫操做的區分規則，代碼層面如何處理好讀命令和寫命令，儘可能無感知無業務入侵。

3. 數據一致性的容忍度。雖然是數據同步，可是因爲網絡的不肯定性這仍然是一個不可忽視的問題。

4. 分庫

數據庫垂直拆分、數據庫水平拆分 統稱 分庫。是指按照特定的條條件和維度，將同一個數據庫中的數據拆分到多個數據庫（主機）上面以達到分散單庫（主機）負載的效果。這樣咱們變相地下降了數據集的大小，以空間換時間來提高性能。

3.1 數據庫垂直拆分

數據庫垂直拆分 指的是按照業務對數據庫中的表進行分組，同組的放到一個新的數據庫（邏輯上，並不是實例）中。須要從實際業務出發將大業務分割成小業務。好比商城的整個業務中的 用戶相關表，訂單相關表，物流相關表 各自獨立分類造成 用戶系統數據庫，訂單系統數據庫，物流系統數據庫 以下圖：

這樣帶來了一些好處： （a）業務清晰，職責單一 （b）易維護，易擴展 （c）數據服務化 。 同時也有一些負面的做用：（a）提升了整個應用的複雜度，並且會造成跨庫事務 （b）引起 「木桶效應」，任何一個短板有可能影響整個系統 （c）部分表關係不能 join 只能經過服務相互調用來維繫。甚至因爲網絡問題引起數據不一致。

在須要進行分庫的狀況下，一般可優先考慮垂直拆分。

3.2 數據庫水平拆分

在數據庫垂直拆分後遇到單機數據庫性能瓶頸以後，就能夠考慮數據庫水平拆分了。 之因此先垂直拆分才水平拆分，是由於垂直拆分後數據業務清晰並且單一，更加方便指定水平的標準。好比咱們對商城業務垂直拆分後的 用戶系統 進行水平拆分就比對整個商城業務進行水平拆分好找維度，咱們能夠根據用戶註冊時間的區間、用戶的區域或者用戶 ID 的範圍、 hash 等條件，而後關聯相關表的記錄將數據進行拆分，若是放在整個商城業務上你是以用戶爲準仍是以訂單爲準都不太好考慮。

咱們按照每 100 萬爲區間對用戶系統水平拆分以下：

這種拆分的好處在於： （a）單個庫的容量可控 （b）單挑記錄保證了數據完整性 （c）數據關係能夠經過 join 維持 （d） 避免了跨庫事務 ；缺點一樣存在：（a）拆分規則對編碼有必定的影響 （b）不一樣業務的分區交互須要統籌設計

4. 分表

分表也分爲 數據表垂直拆分 和 數據表水平拆分 。

4.1 數據表垂直拆分

數據表垂直拆分就是縱向地把表中的列分紅多個表，把表從 「寬」 變「窄」。通常遵循如下幾個點進行拆分：

• 冷熱分離，把經常使用的列放在一個表，不經常使用的放在一個表。
• 大字段列獨立存放
• 關聯關係的列緊密的放在一塊兒

咱們把用戶表中經常使用的和不經常使用的並且大字段分離成兩張表：

4.2 數據表的水平拆分

表的水平拆分感受跟庫的水平拆分思想上都是同樣的，只不過粒度不一樣。表結構維持不變。也就是說拆分後數據集的並集等於拆分前的數據集。理解了 3.2 章節 以後這個就沒有什麼可說的了。

5. 總結

這裏簡單闡述了幾個數據庫優化概念，在實際操做中每每會組合使用。咱們在實際操做以前要作好數據量的預估，這樣可以根據預測將來數據的增量來進行選型。業務數據增加較小，經常使用於表的拆分。增加特別大達到上萬級別則能夠選擇分庫，好比一些資金積分流水，歷史記錄之類的。有些時候並非拆分完就萬事大吉了，好比咱們按照地區拆分後，A 地區業務增加很快業績很好，而 B 地區推廣不力競爭激烈業績蕭條，形成了數據傾斜。也會影響分庫分表的指望效果。這須要創建長效的監控預測機制來應對，甚至根據實際狀況及時調整策略。數據拆分還面臨分佈式的不少問題，分佈式事務，高可用，數據一致性，全局惟一性都是應該考慮的問題。若是你有什麼問題能夠經過公衆號：Java知己 與我交流。

關注公衆號：Java知己 獲取更多資訊

[我的博客：https://blog.kotom.cn/)