架构组件:基于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


原文地址:https://www.cnblogs.com/cicada-smile/p/11297223.html

时间: 2024-10-06 11:08:24

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

分库分表数据库中间件对比

(一)关键问题 1.读写分离 2.分库分表 3.类别 lib库 1)业务直接到数据库,少一层proxy效率更高 2)没有proxy的lvs的单点问题 proxy 1)统一管理所有到数据库的连接,连接复用 2)基础查询功能抽象,减少代码耦合 3)易于实现监控.数据迁移.连接管理等功能 (二)sharding-jdbc(开源,lib) 当当应用框架ddframe中,从关系型数据库模块dd-rdb中分离出来的数据库水平分片框架 功能 1)以jar包形式提供服务 2)分片灵活,支持等号.between.

【转】mysql分库分表,数据库分库分表思路

原文:https://www.cnblogs.com/butterfly100/p/9034281.html 复制过来收藏 一. 数据切分 关系型数据库本身比较容易成为系统瓶颈,单机存储容量.连接数.处理能力都有限.当单表的数据量达到1000W或100G以后,由于查询维度较多,即使添加从库.优化索引,做很多操作时性能仍下降严重.此时就要考虑对其进行切分了,切分的目的就在于减少数据库的负担,缩短查询时间. 数据库分布式核心内容无非就是数据切分(Sharding),以及切分后对数据的定位.整合.数据

[转]一种可以避免数据迁移的分库分表scale-out扩容方式

原文地址:http://jm-blog.aliapp.com/?p=590 目前绝大多数应用采取的两种分库分表规则 mod方式 dayofweek系列日期方式(所有星期1的数据在一个库/表,或所有?月份的数据在一个库表) 这两种方式有个本质的特点,就是离散性加周期性. 例如以一个表的主键对3取余数的方式分库或分表: 那么随着数据量的增大,每个表或库的数据量都是各自增长.当一个表或库的数据量增长到了一个极限,要加库或加表的时候, 介于这种分库分表算法的离散性,必需要做数据迁移才能完成.例如从3个扩

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: 注册中心 (

面试官:“谈谈分库分表吧?”

关注偶,领取更多学习资料哦. 1.什么是分库分表 从字面上简单理解,就是将原本存储在一个库的数据分块存储在多个库上,将原本存储在一个表的数据分块存储在多个表里面. 数据的切分根据其切分规则的类型,可以分为如下两种切分模式. 垂直(纵向)切分:把单一的表拆分成多个表,并分散到不同的数据库(主机)上. 比如一个订单表里面有用户信息,商品信息,收货地址信息,促销信息,这样表的字段太多,显得特别臃肿,所以我们将他们各自分隔出来,形成多张表存储数据. 这样操作的优点: 拆分后业务清晰,拆分规则明确. 系统

如何设计可以动态扩容缩容的分库分表方案?

对于分库分表来说,主要是面对以下问题: 选择一个数据库中间件,调研.学习.测试: 设计你的分库分表的一个方案,你要分成多少个库,每个库分成多少个表,比如 3 个库,每个库 4 个表: 基于选择好的数据库中间件,以及在测试环境建立好的分库分表的环境,然后测试一下能否正常进行分库分表的读写: 完成单库单表到分库分表的迁移,双写方案: 线上系统开始基于分库分表对外提供服务: 扩容了,扩容成 6 个库,每个库需要 12 个表,你怎么来增加更多库和表呢? 是你必须面对的一个事儿,就是你已经弄好分库分表方案

分库分布的几件小事(二)如何进行分库分表的数据迁移

1.停机迁移方案 这是最简单的也是最low的迁移方案了,如果系统就算短期停机也没有关系或者造不成多大的影响,可以选用此方案. 首先停掉机器,将系统全都停掉,不要再有新的数据进来,然后使用之前写好的程序,连接旧的数据库,将旧数据库里面的数据读出来,然后通过数据分发中间件写到分库分好的数据里面去.然后修改系统是数据库连接.分库分表配置,然后重新上线. 2.双写不停机迁移方案 双写迁移方案的核心在双写,首先要修改系统所有需要写库的地方,将虽有对数据的写操作不但要写入就库,也要同时写入新库. 然后使用写

如何设计可以动态扩容缩容的分库分表方案

停机扩容(不推荐) 这个方案就跟停机迁移一样,步骤几乎一致,唯一的一点就是那个导数的工具,是把现有库表的数据抽出来慢慢倒入到新的库和表里去.但是最好别这么玩儿,有点不太靠谱,因为既然分库分表就说明数据量实在是太大了,可能多达几亿条,甚至几十亿,你这么玩儿,可能会出问题. 从单库单表迁移到分库分表的时候,数据量并不是很大,单表最大也就两三千万.那么你写个工具,多弄几台机器并行跑,1小时数据就导完了.这没有问题. 如果 3 个库 + 12 个表,跑了一段时间了,数据量都 1~2 亿了.光是导 2 亿

系统从未分库分表动态切换到分库分表

停机迁移方案 我先给你说一个最 low 的方案,就是很简单,大家伙儿凌晨 12 点开始运维,网站或者 app 挂个公告,说 0 点到早上 6 点进行运维,无法访问. 接着到 0 点停机,系统停掉,没有流量写入了,此时老的单库单表数据库静止了.然后你之前得写好一个导数的一次性工具,此时直接跑起来,然后将单库单表的数据哗哗哗读出来,写到分库分表里面去. 导数完了之后,就 ok 了,修改系统的数据库连接配置啥的,包括可能代码和 SQL 也许有修改,那你就用最新的代码,然后直接启动连到新的分库分表上去.

利用ShardingSphere-JDBC实现分库分表

利用ShardingSphere-JDBC实现分库分表 1. ShardingSphere概述 1.1 概述 业务发展到一定程度,分库分表是一种必然的要求,分库可以实现资源隔离,分表则可以降低单表数据量,提高访问效率. 分库分表的技术方案,很久以来都有两种理念: 集中式的Proxy,实现MySQL客户端协议,使用户无感知 分布式的Proxy,在代码层面进行增强,实现一个路由程序 这两种方式是各有利弊的,集中式Proxy的好处是业务没有感知,一切交给DBA把控,分布式的Proxy其支持的语言有限,