架構(gòu)方案：分庫分表模式下，數(shù)據(jù)庫擴(kuò)容方案

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

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

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

這樣分層的架構(gòu)

(1)上層是業(yè)務(wù)層biz，實(shí)現(xiàn)業(yè)務(wù)邏輯封裝;

(2)中間是服務(wù)層service，封裝數(shù)據(jù)訪問;

(3)下層是數(shù)據(jù)層db，存儲(chǔ)業(yè)務(wù)數(shù)據(jù);

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

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

這樣擴(kuò)容的問題

(1)分庫分表的策略導(dǎo)致數(shù)據(jù)遷移量大;

(2)影響數(shù)據(jù)的持續(xù)服務(wù)性;

(3)指定時(shí)間完成，技術(shù)壓力大，容易導(dǎo)致預(yù)想不到的錯(cuò)誤;

如何平穩(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ù)訪問層邏輯

方案描述

基于兩臺(tái)數(shù)據(jù)庫分庫分表，簡(jiǎn)稱：服務(wù)二

基于三臺(tái)數(shù)據(jù)庫分庫分表，簡(jiǎn)稱：服務(wù)三

(1)提供兩套服務(wù)，服務(wù)二和服務(wù)三

(2)數(shù)據(jù)庫擴(kuò)容后，如果訪問服務(wù)三直接獲取到數(shù)據(jù)，流程結(jié)束。

(3)如果訪問服務(wù)三獲取不到數(shù)據(jù)，則訪問服務(wù)二獲取數(shù)據(jù)。

(4)在遷移開始的一段時(shí)間內(nèi)，訪問壓力還會(huì)在服務(wù)二上面。

(5)這樣就做到數(shù)據(jù)訪問服務(wù)不會(huì)停機(jī)。

(6)這種訪問模式基于SpringCloud很容易做到。

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

方案描述

(1)關(guān)閉基于兩臺(tái)庫的數(shù)據(jù)入庫流程

(2)開啟基于三臺(tái)庫的數(shù)據(jù)入庫流程，這樣新入庫數(shù)據(jù)就可以被服務(wù)三直接訪問到。

(3)開發(fā)數(shù)據(jù)遷移中間件，掃描原先兩臺(tái)庫的數(shù)據(jù)。

(4)掃描的數(shù)據(jù)根據(jù)分三臺(tái)庫策略判斷是否需要遷移。

(5)如果數(shù)據(jù)需要遷移，則調(diào)用服務(wù)三的數(shù)據(jù)入庫接口。

(6)數(shù)據(jù)遷移完成后，刪除原來的位置的數(shù)據(jù)。

(7)這種遷移模式基于SpringCloud很容易做到。

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

(1)整個(gè)過程是持續(xù)對(duì)線上提供服務(wù);

(2)數(shù)據(jù)遷移中間件的開發(fā)復(fù)雜度較低;

(3)可以限速慢慢遷移，沒有時(shí)間壓力。