Shard-Jdbc數據庫擴容的場景和問題的解決方法

這篇文章主要介紹“Shard-Jdbc數據庫擴容的場景和問題的解決方法”，在日常操作中，相信很多人在Shard-Jdbc數據庫擴容的場景和問題的解決方法問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”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/spring-cloud-base
GitEE·地址
https://gitee.com/cicadasmile/spring-cloud-base

到此，關于“Shard-Jdbc數據庫擴容的場景和問題的解決方法”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！