一、分庫分表的背景

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

二、如何進行資料切分

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

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

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

垂直切分

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

舉個例子，原資料庫中有商品表、交易表、訂單表，我們可以按照業務的不同進行垂直切分，把商品表、交易表、訂單表分別拆分到商品庫、交易庫、訂單庫中去。

垂直拆分的優點：

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

部分業務表無法關聯（Join），只能通過介面方式解決，提高了系統的複雜度；受每種業務的不同限制，存在單庫效能瓶頸，不易進行資料擴充套件和提升效能；分散式事務處理複雜。

水平切分（重點）

水平切分，強調的是技術層面的拆分。她是將其按照一定的邏輯規則將一個表中的資料分散到多個庫中，在每個表中包含一部分資料，所有表加起來就是全量的資料。簡單來說，我們可以將對資料的水平切分理解為按照資料行進行切分，就是將表中的某些行切分到一個數據庫表中，而將其他行切分到其他資料庫表中。

比如，原資料庫有一張交易記錄表，資料量非常大，其中表中有個地區欄位，經過深入考證符合水平拆分的條件。我們就按照這個欄位進行水平拆分，按不同的地區（北京、上海、江蘇、浙江、廣東等）拆分成10個庫。

高峰時段同時有100萬次請求，如果是單庫，資料庫就會承受100萬次的請求壓力，拆分成100個表分別放入10個庫中，每個表進行1萬次請求，則每個資料庫會承受10萬次的請求壓力，這樣壓力就減少了很多，並且是成倍減少的。

水平拆分的優點：

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

拆分規則不好抽象；分片事務一致性難以解決；資料多次擴充套件難度大；跨庫 join 效能較差。

三、資料切分導致的一些問題

上面我們也講了兩種資料切分方式的優點和缺點，但是他們有些共同的缺點，

分散式事務的問題；跨節點 Join 的問題；跨節點合併排序分頁的問題；多資料來源管理問題。一般來說，業務上存在著複雜 join 的場景是很難切分的，往往業務獨立的易於切分。如何切分，我們遵循如下原則，

能不切分儘量不要切分；如果要切分一定要選擇合適的切分規則，提前規劃好；資料切分儘量通過資料冗餘或表分組來降低跨庫 Join 的可能；由於資料庫中介軟體對資料 Join 實現的優劣難以把握，而且實現高效能難度極大，業務讀取儘量少使用多表 Join。

四、資料來源管理的問題

分庫分表之後，資料來源的管理是系統實現的關鍵。

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

客戶端模式，也就是在每個應用程式模組中配置管理自己需要的一個（或者多個）資料來源，直接訪問各個資料庫，在模組內完成資料的整合。比如可以依賴spring註解實現。中間代理模式，統一管理所有的資料來源，後端資料庫叢集對前端應用程式透明。考慮到系統的複雜性和擴充套件性，建議第二種中間代理模式。雖然短期內需要付出的成本可能會相對更大一些，但是對整個系統的擴充套件性來說，是非常實用的。

2. 中介軟體層面

上面的系統層面，需要的程式碼實現比較複雜，中介軟體是在資料叢集前面加一層代理，比如Cobar、Mycat等資料庫中介軟體。實用資料庫中介軟體，對程式碼層面的實現是很大的解放。

五、分散式事務的解決方案

分庫分表導致的最突出的問題就是分散式事務的處理。大家如果有興趣可以參考下之前的文章網際網路架構下的分散式技術面試要點概覽中的分散式事務部分，後面如果有時間，可以單獨再探討