1. 前言

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

2. 讀寫分離

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

2.1 為什麼要讀寫分離

大多數互聯網數據操作往往都是讀多寫少，隨着數據的增長，數據庫的“讀”會首先成為瓶頸。如果我們希望能線性地提升數據庫的讀性能和寫性能，就需要讓讀寫儘可能的不相互影響，各自為政。在使用讀寫分離之前我們應該考慮使用緩存能不能解決問題。然後再考慮對數據庫按照 “讀” 和 “寫” 進行分組。讀寫分離意味着將一體的結構的進行分散，在數據量大、高並發的情景中要考慮以下這些問題

1. 如何保證 Master 的高可用，故障轉移，熔斷限流等。
2. 讀寫操作的區分規則，代碼層面如何處理好讀命令和寫命令，盡量無感知無業務入侵。
3. 數據一致性的容忍度。雖然是數據同步，但是由於網絡的不確定性這仍然是一個不可忽視的問題。

3. 分庫

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

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 地區推廣不力競爭激烈業績蕭條，造成了數據傾斜。也會影響分庫分表的期望效果。這需要建立長效的監控預測機制來應對，甚至根據實際情況及時調整策略。數據拆分還面臨分布式的很多問題，分布式事務，高可用，數據一致性，全局唯一性都是應該考慮的問題。希望我的講解能夠幫助你，還希望多多關注！