架構方案：分庫分表模式下，數據庫擴容方案

一、數據庫擴容

1、業(yè)務場景

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

這樣分層的架構

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

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

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

2、擴容場景和問題

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

這樣擴容的問題

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

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

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

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

二、擴容解決方案

1、擴容方案圖解

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

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

2、解決擴容問題

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

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

3、數據訪問層邏輯

方案描述

基于兩臺數據庫分庫分表，簡稱：服務二

基于三臺數據庫分庫分表，簡稱：服務三

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

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

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

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

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

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

4、數據遷移層邏輯

方案描述

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

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

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

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

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

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

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

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

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

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

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