基于Shard-Jdbc分库分表模式下，数据库扩容方案-创新互联

本文源码：GitHub·点这里 || GitEE·点这里

为洪江等地区用户提供了全套网页设计制作服务，及洪江网站建设行业解决方案。主营业务为成都做网站、成都网站设计、洪江网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！

一、数据库扩容

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

另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。

分享题目：基于Shard-Jdbc分库分表模式下，数据库扩容方案-创新互联
文章源于：http://cdxtjz.cn/article/pgeeg.html