架構組件：基於Shard Jdbc分庫分表，資料庫擴容方案 一、資料庫擴容 1、業務場景 互聯網項目中有很多“數據量大，業務複雜度高，需要分庫分表”的業務場景。 這樣分層的架構 （1）上層是業務層biz，實現業務邏輯封裝； （2）中間是服務層service，封裝數據訪問； （3）下層是數據層db，存 ...
架構組件：基於Shard-Jdbc分庫分表，資料庫擴容方案
一、資料庫擴容
1、業務場景
互聯網項目中有很多“數據量大，業務複雜度高，需要分庫分表”的業務場景。
這樣分層的架構
（1）上層是業務層biz，實現業務邏輯封裝；
（2）中間是服務層service，封裝數據訪問；
（3）下層是數據層db，存儲業務數據；
2、擴容場景和問題
當數據量持續新增，面臨著這樣一些需求，兩台資料庫無法容納，需要資料庫擴容，這裡選擇2台—擴容到3台的模式，如下圖：
這樣擴容的問題
（1）分庫分表的策略導致數據遷移量大；
（2）影響數據的持續服務性；
（3）指定時間完成，技術壓力大，容易導致預想不到的錯誤；
如何平穩不停機遷移數據，保證系統持續服務，是本文將要討論的問題。
二、擴容解決方案
1、擴容方案圖解
（1）分庫分表基於MySQL資料庫，使用shard-jdbc中間件
（2）該方案的思路整體基於SpringCloud微服務架構
2、解決擴容問題
（1）擴容情況下不需要暫停服務；
（2）數據遷移的壓力小，不需要指定時間；
3、數據訪問層邏輯
方案描述
基於兩台資料庫分庫分表，簡稱：服務二
基於三台資料庫分庫分表，簡稱：服務三
（1）提供兩套服務，服務二和服務三
（2）資料庫擴容後，如果訪問服務三直接獲取到數據，流程結束。
（3）如果訪問服務三獲取不到數據，則訪問服務二獲取數據。
（4）在遷移開始的一段時間內，訪問壓力還會在服務二上面。
（5）這樣就做到數據訪問服務不會停機。
（6）這種訪問模式基於SpringCloud很容易做到。
4、數據遷移層邏輯
方案描述
（1）關閉基於兩台庫的數據入庫流程
（2）開啟基於三台庫的數據入庫流程，這樣新入庫數據就可以被服務三直接訪問到。
（3）開發數據遷移中間件，掃描原先兩台庫的數據。
（4）掃描的數據根據分三台庫策略判斷是否需要遷移。
（5）如果數據需要遷移，則調用服務三的數據入庫介面。
（6）數據遷移完成後，刪除原來的位置的數據。
（7）這種遷移模式基於SpringCloud很容易做到。
5、該方案遷移的優點
（1）整個過程是持續對線上提供服務；
（2）數據遷移中間件的開發複雜度較低；
（3）可以限速慢慢遷移，沒有時間壓力；
三、源代碼管理
GitHub地址：知了一笑
https://github.com/cicadasmile
碼雲地址：知了一笑
https://gitee.com/cicadasmile
