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

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

1、業(yè)務場景

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

這樣分層的架構

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

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

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

2、擴容場景和問題

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

這樣擴容的問題

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

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

(3)指定時間完成，技術壓力大，容易導致預想不到的錯誤;

如何平穩(wěn)不停機遷移數(shù)據(jù)，保證系統(tǒng)持續(xù)服務。

二、擴容解決方案

1、擴容方案圖解

(1)分庫分表基于MySQL數(shù)據(jù)庫，使用shard-jdbc中間件

(2)該方案的思路整體基于SpringCloud微服務架構

2、解決擴容問題

(1)擴容情況下不需要暫停服務;

(2)數(shù)據(jù)遷移的壓力小，不需要指定時間;

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

方案描述

基于兩臺數(shù)據(jù)庫分庫分表，簡稱：服務二

基于三臺數(shù)據(jù)庫分庫分表，簡稱：服務三

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

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

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

(4)在遷移開始的一段時間內，訪問壓力還會在服務二上面。

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

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

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

方案描述

(1)關閉基于兩臺庫的數(shù)據(jù)入庫流程

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

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

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

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

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

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

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

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

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

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