超實用的mysql分庫分表策略，輕鬆解決億級數據問題

 

 

1、分庫分表的背景

在數據爆炸的年代，單表數據達到千萬級別，甚至過億的量，都是很常見的情景。這時候再對數據庫進行操做就是很是吃力的事情了，select個半天都出不來數據，這時候業務已經難以維繫。不得已，分庫分表提上日程，咱們的目的很簡單，減少數據庫的壓力，縮短表的操做時間。

 

 

 

2、如何進行數據切分

數據切分（Sharding），簡單的來講，就是經過某種特定的條件，將存放在同一個數據庫中的數據拆分存放到多個數據庫（主機）中，從而達到分散單臺機器負載的狀況，即分庫分表。根據數據切分規則的不一樣，主要有兩種模式，

垂直切分（縱向切分），是對不一樣的表（或者Schema）進行切分，存儲到不一樣的數據庫（主機）之上。

水平切分（橫向切分），是對同一個表中的數據進行切分，存儲到不一樣的數據庫（主機）之上。規則是根據表中數據的邏輯關係，按照某種條件拆分。

 

垂直切分

垂直切分，強調的是業務的拆分。一個數據庫由多個表構成，每一個表對應不一樣的業務，那麼咱們能夠指按照業務的不一樣將表進行分類，並將其分佈到不一樣的數據庫上，這樣就將數據分攤到了不一樣的庫上面，作到專庫專用。

舉個例子，原數據庫中有商品表、交易表、訂單表，咱們能夠按照業務的不一樣進行垂直切分，把商品表、交易表、訂單表分別拆分到商品庫、交易庫、訂單庫中去。

 

 

 

垂直拆分的優勢：

拆分規則明確，拆分後業務清晰；系統之間進行整合或擴展變的容易；數據維護變的容易；按照成本、應用的等級、應用的類型等將表放到不一樣的機器上，便於管理。垂直拆分的缺點：

部分業務表沒法關聯（Join），只能經過接口方式解決，提升了系統的複雜度；受每種業務的不一樣限制，存在單庫性能瓶頸，不易進行數據擴展和提高性能；分佈式事務處理複雜。

 

水平切分（重點）

水平切分，強調的是技術層面的拆分。她是將其按照必定的邏輯規則將一個表中的數據分散到多個庫中，在每一個表中包含一部分數據，全部表加起來就是全量的數據。簡單來講，咱們能夠將對數據的水平切分理解爲按照數據行進行切分，就是將表中的某些行切分到一個數據庫表中，而將其餘行切分到其餘數據庫表中。

好比，原數據庫有一張交易記錄表，數據量很是大，其中表中有個地區字段，通過深刻考證符合水平拆分的條件。咱們就按照這個字段進行水平拆分，按不一樣的地區（北京、上海、江蘇、浙江、廣東等）拆分紅10個庫。

高峯時段同時有100萬次請求，若是是單庫，數據庫就會承受100萬次的請求壓力，拆分紅100個表分別放入10個庫中，每一個表進行1萬次請求，則每一個數據庫會承受10萬次的請求壓力，這樣壓力就減小了不少，而且是成倍減小的。

 

 

 

水平拆分的優勢：

拆分規則抽象好，join 操做基本能夠數據庫作；不存在單庫大數據，高併發的性能瓶頸；應用端改造較少；提升了系統的穩定性跟負載能力。水平拆分的缺點：

拆分規則很差抽象；分片事務一致性難以解決；數據屢次擴展難度大；跨庫 join 性能較差。

 

3、數據切分致使的一些問題

上面咱們也講了兩種數據切分方式的優勢和缺點，可是他們有些共同的缺點，

分佈式事務的問題；跨節點 Join 的問題；跨節點合併排序分頁的問題；多數據源管理問題。通常來講，業務上存在着複雜 join 的場景是很難切分的，每每業務獨立的易於切分。如何切分，咱們遵循以下原則，

能不切分儘可能不要切分；若是要切分必定要選擇合適的切分規則，提早規劃好；數據切分儘可能經過數據冗餘或表分組來下降跨庫 Join 的可能；因爲數據庫中間件對數據 Join 實現的優劣難以把握，並且實現高性能難度極大，業務讀取儘可能少使用多表 Join。

 

4、數據源管理的問題

分庫分表以後，數據源的管理是系統實現的關鍵。

系統應用層面系統應用代碼層面，目前主要有兩種思路，

客戶端模式，也就是在每一個應用程序模塊中配置管理本身須要的一個（或者多個）數據源，直接訪問各個數據庫，在模塊內完成數據的整合。好比能夠依賴spring註解實現。中間代理模式，統一管理全部的數據源，後端數據庫集羣對前端應用程序透明。考慮到系統的複雜性和擴展性，建議第二種中間代理模式。雖然短時間內須要付出的成本可能會相對更大一些，可是對整個系統的擴展性來講，是很是實用的。

2. 中間件層面

上面的系統層面，須要的代碼實現比較複雜，中間件是在數據集羣前面加一層代理，好比Cobar、Mycat等數據庫中間件。實用數據庫中間件，對代碼層面的實現是很大的解放。

 

 

5、分佈式事務的解決方案

分庫分表致使的最突出的問題就是分佈式事務的處理。你們若是有興趣能夠參考下以前的文章互聯網架構下的分佈式技術面試要點概覽中的分佈式事務部分，後面若是有時間，能夠單獨再探討下。