基于Shard-Jdbc分库分表，数据库扩容方案

亦凉 2023-07-10 15:34 34阅读 0赞

# 一、数据库扩容 #

## 1、业务场景 ##

互联网项目中有很多“数据量大，业务复杂度高，需要分库分表”的业务场景。

![图片描述][format_png]

这样分层的架构  
（1）上层是业务层biz，实现业务逻辑封装；  
（2）中间是服务层service，封装数据访问；  
（3）下层是数据层db，存储业务数据；

## 2、扩容场景和问题 ##

当数据量持续新增，面临着这样一些需求，两台数据库无法容纳，需要数据库扩容，这里选择2台—扩容到3台的模式，如下图：

![图片描述][format_png 1]

这样扩容的问题  
（1）分库分表的策略导致数据迁移量大；  
（2）影响数据的持续服务性；  
（3）指定时间完成，技术压力大，容易导致预想不到的错误；

如何平稳不停机迁移数据，保证系统持续服务，是本文将要讨论的问题。

# 二、扩容解决方案 #

## 1、扩容方案图解 ##

![图片描述][format_png 2]

（1）分库分表基于MySQL数据库，使用shard-jdbc中间件  
（2）该方案的思路整体基于SpringCloud微服务架构

## 2、解决扩容问题 ##

（1）扩容情况下不需要暂停服务；  
（2）数据迁移的压力小，不需要指定时间；

## 3、数据访问层逻辑 ##

![图片描述][format_png 3]

方案描述  
基于两台数据库分库分表，简称：服务二  
基于三台数据库分库分表，简称：服务三  
（1）提供两套服务，服务二和服务三  
（2）数据库扩容后，如果访问服务三直接获取到数据，流程结束。  
（3）如果访问服务三获取不到数据，则访问服务二获取数据。  
（4）在迁移开始的一段时间内，访问压力还会在服务二上面。  
（5）这样就做到数据访问服务不会停机。  
（6）这种访问模式基于SpringCloud很容易做到。

## 4、数据迁移层逻辑 ##

![图片描述][format_png 4]

方案描述  
（1）关闭基于两台库的数据入库流程  
（2）开启基于三台库的数据入库流程，这样新入库数据就可以被服务三直接访问到。  
（3）开发数据迁移中间件，扫描原先两台库的数据。  
（4）扫描的数据根据分三台库策略判断是否需要迁移。  
（5）如果数据需要迁移，则调用服务三的数据入库接口。  
（6）数据迁移完成后，删除原来的位置的数据。  
（7）这种迁移模式基于SpringCloud很容易做到。

## 5、该方案迁移的优点 ##

（1）整个过程是持续对线上提供服务；  
（2）数据迁移中间件的开发复杂度较低；  
（3）可以限速慢慢迁移，没有时间压力；

# 三、源代码管理 #

GitHub地址：知了一笑
    https://github.com/cicadasmile
    码云地址：知了一笑
    https://gitee.com/cicadasmile

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJ3eGd5?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJ3eGg1?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJ3eGg3?x-oss-process=image/format,png
[format_png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJ3eGg4?x-oss-process=image/format,png
[format_png 4]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJ3eGli?x-oss-process=image/format,png