SpringCloud实现ShardJdbc分库分表模式下,数据库扩容方案

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

一、项目结构

1、工程结构

2、模块命名

shard-common-entity:   公共代码块
shard-open-inte:        开放接口管理
shard-eureka-7001:      注册中心
shard-two-provider-8001: 8001 基于两台库的服务
shard-three-provider-8002:8002 基于三台库的服务

3、代码依赖结构

4、项目启动顺序

(1)shard-eureka-7001:        注册中心
(2)shard-two-provider-8001:  8001 基于两台库的服务
(3)shard-three-provider-8002:8002 基于三台库的服务

按照顺序启动,且等一个服务完全启动后,在启动下一个服务,不然可能遇到一些坑。

二、核心代码块

1、8001 服务提供一个对外服务

基于Feign的调用方式
作用:基于两台分库分表的数据查询接口。

import org.springframework.cloud.netflix.feign.FeignClient;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import shard.jdbc.common.entity.TableOne;
/**
 * shard-two-provider-8001
 * 对外开放接口
 */
@FeignClient(value = "shard-provider-8001")
public interface TwoOpenService {
    @RequestMapping("/selectOneByPhone/{phone}")
    TableOne selectOneByPhone(@PathVariable("phone") String phone) ;
}

2、8002 服务提供一个对外服务

基于Feign的调用方式
作用:基于三台分库分表的数据存储接口。

import org.springframework.cloud.netflix.feign.FeignClient;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import shard.jdbc.common.entity.TableOne;

/**
 * 数据迁移服务接口
 */
@FeignClient(value = "shard-provider-8002")
public interface MoveDataService {
    @RequestMapping("/moveData")
    Integer moveData (@RequestBody TableOne tableOne) ;
}

3、基于8002服务数据查询接口

查询流程图

代码块

/**
 * 8001 端口 :基于两台分库分表策略的数据查询接口
 */
@Resource
private TwoOpenService twoOpenService ;
@Override
public TableOne selectOneByPhone(String phone) {
    TableOne tableOne = tableOneMapper.selectOneByPhone(phone);
    if (tableOne != null){
        LOG.info("8002 === >> tableOne :"+tableOne);
    }
    // 8002 服务没有查到数据
    if (tableOne == null){
        // 调用 8001 开放的查询接口
        tableOne = twoOpenService.selectOneByPhone(phone) ;
        LOG.info("8001 === >> tableOne :"+tableOne);
    }
    return tableOne ;
}

4、基于 8001 数据扫描迁移代码

迁移流程图

代码块

/**
 * 8002 端口开放的数据入库接口
 */
@Resource
private MoveDataService moveDataService ;
/**
 * 扫描,并迁移数据
 * 以 库 db_2 的 table_one_1 表为例
 */
@Override
public void scanDataRun() {
    String sql = "SELECT id,phone,back_one backOne,back_two backTwo,back_three backThree FROM table_one_1" ;
    // dataTwoTemplate 对应的数据库:ds_2
    List<TableOne> tableOneList = dataTwoTemplate.query(sql,new Object[]{},new BeanPropertyRowMapper<>(TableOne.class)) ;
    if (tableOneList != null && tableOneList.size()>0){
        int i = 0 ;
        for (TableOne tableOne : tableOneList) {
            String db_num = HashUtil.moveDb(tableOne.getPhone()) ;
            String tb_num = HashUtil.moveTable(tableOne.getPhone()) ;
            // 只演示向数据新加库 ds_4 迁移的数据
            if (db_num.equals("ds_4")){
                i += 1 ;
                LOG.info("迁移总数数=>" + i + "=>库位置=>"+db_num+"=>表位置=>"+tb_num+"=>数据:【"+tableOne+"】");
                // 扫描完成:执行新库迁移和旧库清理过程
                moveDataService.moveData(tableOne) ;
                // dataTwoTemplate.update("DELETE FROM table_one_1 WHERE id=? AND phone=?",tableOne.getId(),tableOne.getPhone());
            }
        }
    }
}

三、演示执行流程

1、项目流程图

2、测试执行流程

(1)、访问8002 数据查询端口

http://127.0.0.1:8002/selectOneByPhone/phone20
日志输出:
8001 服务查询到数据
8001 === >> tableOne :+{tableOne}

(2)、执行8001 数据扫描迁移

http://127.0.0.1:8001/scanData

(3)、再次访问8002 数据查询端口

http://127.0.0.1:8002/selectOneByPhone/phone20
日志输出:
8002 服务查询到数据
8002 === >> tableOne :+{tableOne}

四、源代码地址

GitHub·地址
https://github.com/cicadasmile/spring-cloud-base
GitEE·地址
https://gitee.com/cicadasmile/spring-cloud-base

原文地址:https://blog.51cto.com/14439672/2443993

时间: 2024-11-05 21:39:33

SpringCloud实现ShardJdbc分库分表模式下,数据库扩容方案的相关文章

基于Shard-Jdbc分库分表模式下,数据库扩容方案

本文源码:GitHub·点这里 || GitEE·点这里 一.数据库扩容 1.业务场景 互联网项目中有很多"数据量大,业务复杂度高,需要分库分表"的业务场景. 这样分层的架构(1)上层是业务层biz,实现业务逻辑封装:(2)中间是服务层service,封装数据访问:(3)下层是数据层db,存储业务数据: 2.扩容场景和问题 当数据量持续新增,面临着这样一些需求,两台数据库无法容纳,需要数据库扩容,这里选择2台-扩容到3台的模式,如下图: 这样扩容的问题(1)分库分表的策略导致数据迁移量

分库分表 or NewSQL数据库?终于看懂应该怎么选!【转】

最近与同行科技交流,经常被问到分库分表与分布式数据库如何选择,网上也有很多关于中间件+传统关系数据库(分库分表)与NewSQL分布式数据库的文章,但有些观点与判断是我觉得是偏激的,脱离环境去评价方案好坏其实有失公允.本文通过对两种模式关键特性实现原理对比,希望可以尽可能客观.中立的阐明各自真实的优缺点以及适用场景. 一.NewSQL数据库先进在哪儿? 首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题,国外有篇论文pavlo-newsql-sigmodrec,如果根据该文中

架构组件:基于Shard-Jdbc分库分表,数据库扩容方案

一.数据库扩容 1.业务场景 互联网项目中有很多"数据量大,业务复杂度高,需要分库分表"的业务场景. 这样分层的架构 (1)上层是业务层biz,实现业务逻辑封装: (2)中间是服务层service,封装数据访问: (3)下层是数据层db,存储业务数据: 2.扩容场景和问题 当数据量持续新增,面临着这样一些需求,两台数据库无法容纳,需要数据库扩容,这里选择2台-扩容到3台的模式,如下图: 这样扩容的问题 (1)分库分表的策略导致数据迁移量大: (2)影响数据的持续服务性: (3)指定时间

【转】MySQL分库分表环境下全局ID生成方案

转载一篇博客,里面有很多的知识和思想值得我们去思考. —————————————————————————————————————————————————————————————————————— 在大型互联网应用中,随着用户数的增加,为了提高应用的性能,我们经常需要对数据库进行分库分表操作.在单表时代,我们可以完全依赖于数据库的自增ID来唯一标识一个用户或数据对象.但是当我们对数据库进行了分库分表后,就不能依赖于每个表的自增ID来全局唯一标识这些数据了.因此,我们需要提供一个全局唯一的ID号生成

170123、数据库分库分表策略的具体实现方案

相关文章: 1. 使用Spring AOP实现MySQL数据库读写分离案例分析 2.MySQL5.6 数据库主从(Master/Slave)同步安装与配置详解 :http://blog.csdn.net/xlgen157387/article/details/51331244 3.MySQL主从复制的常见拓扑.原理分析以及如何提高主从复制的效率总结 :http://blog.csdn.net/xlgen157387/article/details/52451613 4.使用mysqlreplic

数据库分库分表策略的具体实现方案

一.MySQL扩展具体的实现方式 随着业务规模的不断扩大,需要选择合适的方案去应对数据规模的增长,以应对逐渐增长的访问压力和数据量. 关于数据库的扩展主要包括:业务拆分.主从复制,数据库分库与分表.这篇文章主要讲述数据库分库与分表 (1)业务拆分 业务起步初始,为了加快应用上线和快速迭代,很多应用都采用集中式的架构.随着业务系统的扩大,系统变得越来越复杂,越来越难以维护,开发效率变得越来越低,并且对资源的消耗也变得越来越大,通过硬件提高系统性能的方式带来的成本也越来越高. 因此,在选型初期,一个

MySQL分库分表之MyCat实现(五)

一 .分库分表 什么是分库分表? 分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题,将原来独立的数据库拆分成若干数据库组成,将数据大表分成若干数据表组成,使得单一数据库.单一数据表的数据量变小,从而达到提升数据库性能的目的. 2.分库分表的方式 2.1分库: 1.垂直分库:是指按照业务将表进行分类,分布到不同的数据库上面,每个库可以放不同的服务器上,它的核心理念是专库专用. 2水平分库:把同一个表的数据按一定规则拆分到不同的数据库中,每个库可以放不同的服务器上 2.2分表: 1.垂直

数据库分库分表

1. 数据库分库分表 1.1. 前言 1.1.1. 名词解释 1.2. 数据库架构演变 1.3. 分库分表前的问题 1.3.1. 用户请求量太大 1.3.2. 单库太大 1.3.3. 单表太大 1.4. 分库分表的方式方法 1.4.1. 垂直拆分 1.4.2. 水平拆分 1.5. 分库分表后面临的问题 1.5.1. 事务支持 1.5.2. 多库结果集合并(group by,order by) 1.5.3. 跨库join 1.6. 分库分表方案产品 1.7. 为什么不建议分库分表 1.8. 参考

数据库架构演变及分库分表

当生产环境中业务量激增,数据库数据量也会极具增加.当数据库的数据量达到一定程度时(数据库瓶颈),数据库宿主机负载超高,会严重影响业务,严重时会导致数据库宕机.为了避免这种极端情况的发生,我们应当在发生前做好预案,用于解决数据库数据量过载的问题.以下是我个人工作中使用的解决方案:1)数据库主从或多主多从方案2)数据库冷热数据拆分3)数据库分库分表操作4)在数据库前端增加缓存redis或memcached 一开始时,公司部分业务的架构如下(全都是单节点情况)经过自己强调该架构严重的缺点:节点单一,服