架構(gòu)組件：基于Shard-Jdbc分庫分表，數(shù)據(jù)庫擴容方案

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

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

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

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

2、擴容場景和問題

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

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

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

二、擴容解決方案

1、擴容方案圖解

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

2、解決擴容問題

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

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

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

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

三、寫在最后

下一篇文章會更新該方案基于SpringCloud的代碼實現(xiàn)。

總結(jié)

以上是生活随笔為你收集整理的架构组件：基于Shard-Jdbc分库分表，数据库扩容方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。