基于Shard-Jdbc分庫分表模式下，數(shù)據(jù)庫擴(kuò)容方案

本文源碼：GitHub·點(diǎn)這里 || GitEE·點(diǎn)這里

一、數(shù)據(jù)庫擴(kuò)容

1、業(yè)務(wù)場景

互聯(lián)網(wǎng)項(xiàng)目中有很多“數(shù)據(jù)量大，業(yè)務(wù)復(fù)雜度高，需要分庫分表”的業(yè)務(wù)場景。

這樣分層的架構(gòu)
（1）上層是業(yè)務(wù)層biz，實(shí)現(xiàn)業(yè)務(wù)邏輯封裝；
（2）中間是服務(wù)層service，封裝數(shù)據(jù)訪問；
（3）下層是數(shù)據(jù)層db，存儲業(yè)務(wù)數(shù)據(jù)；

2、擴(kuò)容場景和問題

當(dāng)數(shù)據(jù)量持續(xù)新增，面臨著這樣一些需求，兩臺數(shù)據(jù)庫無法容納，需要數(shù)據(jù)庫擴(kuò)容，這里選擇2臺—擴(kuò)容到3臺的模式，如下圖：

這樣擴(kuò)容的問題
（1）分庫分表的策略導(dǎo)致數(shù)據(jù)遷移量大；
（2）影響數(shù)據(jù)的持續(xù)服務(wù)性；
（3）指定時(shí)間完成，技術(shù)壓力大，容易導(dǎo)致預(yù)想不到的錯誤；

如何平穩(wěn)不停機(jī)遷移數(shù)據(jù)，保證系統(tǒng)持續(xù)服務(wù)，是本文將要討論的問題。

二、擴(kuò)容解決方案

1、擴(kuò)容方案圖解

（1）分庫分表基于MySQL數(shù)據(jù)庫，使用shard-jdbc中間件
（2）該方案的思路整體基于SpringCloud微服務(wù)架構(gòu)

2、解決擴(kuò)容問題

（1）擴(kuò)容情況下不需要暫停服務(wù)；
（2）數(shù)據(jù)遷移的壓力小，不需要指定時(shí)間；

3、數(shù)據(jù)訪問層邏輯

方案描述
基于兩臺數(shù)據(jù)庫分庫分表，簡稱：服務(wù)二
基于三臺數(shù)據(jù)庫分庫分表，簡稱：服務(wù)三
（1）提供兩套服務(wù)，服務(wù)二和服務(wù)三
（2）數(shù)據(jù)庫擴(kuò)容后，如果訪問服務(wù)三直接獲取到數(shù)據(jù)，流程結(jié)束。
（3）如果訪問服務(wù)三獲取不到數(shù)據(jù)，則訪問服務(wù)二獲取數(shù)據(jù)。
（4）在遷移開始的一段時(shí)間內(nèi)，訪問壓力還會在服務(wù)二上面。
（5）這樣就做到數(shù)據(jù)訪問服務(wù)不會停機(jī)。
（6）這種訪問模式基于SpringCloud很容易做到。

4、數(shù)據(jù)遷移層邏輯

方案描述
（1）關(guān)閉基于兩臺庫的數(shù)據(jù)入庫流程
（2）開啟基于三臺庫的數(shù)據(jù)入庫流程，這樣新入庫數(shù)據(jù)就可以被服務(wù)三直接訪問到。
（3）開發(fā)數(shù)據(jù)遷移中間件，掃描原先兩臺庫的數(shù)據(jù)。
（4）掃描的數(shù)據(jù)根據(jù)分三臺庫策略判斷是否需要遷移。
（5）如果數(shù)據(jù)需要遷移，則調(diào)用服務(wù)三的數(shù)據(jù)入庫接口。
（6）數(shù)據(jù)遷移完成后，刪除原來的位置的數(shù)據(jù)。
（7）這種遷移模式基于SpringCloud很容易做到。

5、該方案遷移的優(yōu)點(diǎn)

（1）整個過程是持續(xù)對線上提供服務(wù)；
（2）數(shù)據(jù)遷移中間件的開發(fā)復(fù)雜度較低；
（3）可以限速慢慢遷移，沒有時(shí)間壓力；

三、源代碼管理

GitHub·地址
https://github.com/cicadasmile/spring-cloud-base
GitEE·地址
https://gitee.com/cicadasmile/spring-cloud-base