分庫分表介紹

1、背景

讀寫分離是爲了擴展數據庫的讀能力，分庫分表則是爲了擴展數據庫的寫能力。

一旦業務表中數據太大（對於mysql,單表數據通常不超過3000w,單庫不超過300G），不管是任何CRUD操做，所耗費資源和性能都極大。這個時候通常就須要

分庫分表，將海量數據分配給N個子表維護。

2、分庫分表優勢

分庫優勢：下降單臺機器的負載壓力

分表優勢：提升數據操做的效率

3、分庫分表的挑戰

主要體如今四個方面：基本的數據增、刪、改操做，分佈式ID生成，分佈式事務，動態擴容。

3.1 對於研發人員，即便分庫分表，咱們仍然但願可以像單表那樣去操做數據庫。

例如咱們但願插入四條用戶記錄：

insert into user(id,name) values (1,」tianshouzhi」),(2,」huhuamin」), (3,」wanghanao」),(4,」luyang」)

　　而在分庫分表以後，這樣的sql已經沒法執行。只有將sql轉化爲以下形式才能夠執行：

insert into user_1(id,name) values (1,」tianshouzhi」)
insert into user_2(id,name) values (2,」huhuamin」)
insert into user_3(id,name) values (3,」wanghanao」)
insert into user_0(id,name) values  (4,」luyang」)

　　

3.2 分佈式ID

在分庫分表後，咱們不能再使用mysql的自增主鍵。由於在插入記錄的時候，不一樣的庫生成的記錄的自增id可能會出現衝突。所以須要有一個全局的id生成器。

3.3 分佈式事務

例如上面的批量插入記錄到四個不一樣的庫，如何保證要麼同時成功，要麼同時失敗。關於分佈式事務，mysql支持XA事務，可是效率較低。柔性事務是目前比較主流的方案，柔性事務包括：最大努力通知型、可靠消息最終一致性方案以及TCC兩階段提交。

3.4 動態擴容

動態擴容指的是增長分庫分表的數量。

例如原來的user表拆分到2個庫的四張表上。如今咱們但願將分庫的數量變爲4個，分表的數量變爲8個。這種狀況下通常要伴隨着數據遷移。例如在4張表的狀況下，id爲7的記錄，7%4=3，所以這條記錄位於user_3這張表上。可是如今分表的數量變爲了8個，而7%8=7，而user_7這張表上根本就沒有id=7的這條記錄，所以若是不進行數據遷移的話，就會出現記錄找不到的狀況。