系统?基于Spring Boot框架,springBoot项目简单使用sharding-jdbc,利用sharding-jdbc实现简单,分区分表,读写分离。
ShardingSphere简介 Apache ShardingSphere(Incubator) 是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar(规划中)这3款相互独立,却又能够混合部署配合使用的产品组成。它们均提供标准化的数据分片、分布式事务和数据库治理功能,可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。 ShardingSphere定位为关系型数据库中间件,旨在充分合理地在分布式
真怕标题起的太高大上,吓得都不敢看了, 其实非常非常简单, 还是springboot 熟悉的风格, 引依赖,加配置就可以用了!! 真的,童叟无欺, 跟着写,做不出来,你就来找小刀!!
Sharding-JDBC是分布式数据中间件Sharding-Sphere中的重要组成部分,官方的介绍如下:
在Matrix-web后台管理系统中,使用到了数据库的读写分离技术。采用的开源的Sharding-JDBC作为数据库读写分离的框架。Matrix-Web后台数据库这一块采用的技术栈如下:
之前的几篇文章,阿粉已经说了这个SpringBoot整合 Sharding-JDBC 实现了水平的分库分表,也是我们在日常的业务中最经常用到的,把数据进行水平分库,比如按照日期分库,按照奇偶性用户ID来水平分库,今天阿粉来说说如何使用 Sharding-JDBC 进行垂直切分表和数据库。
在我《Spring Cloud微服务-全栈技术与案例解析》书中,第18章节分库分表解决方案里有对Sharding-JDBC的使用进行详细的讲解。
因为市面上已经非常不错的分库分表的资料,所以艿艿就不在尴尬的瞎哔哔一些内容。推荐阅读两个资料:
这里为了方便,我在接口中添加了参数,可以指定活动id,因为我们的库和表都是 activity_id % 2得到,所以通过设置奇偶数,判断分片策略是否生效
在实际业务中,单表数据增长较快,很容易达到数据瓶颈,比如单表百万级别数据量。当数据量继续增长时,数据的查询性能即使有索引的帮助下也不尽如意,这时可以引入数据分库分表技术。
把存于一个库的数据分散到多个库中,把存于一个表的数据分散到多个表中。如果说读写分离是为了分散数据库读写操作压力,分库分表就是为了分散存储压力
读写分离,基本的原理是让主数据库处理事务性增、改、删操作,而从数据库处理SELECT查询操作,让两者分工明确达到提高数据库整体读写性能。当然,主数据库另外一个功能就是负责将事务性查询导致的数据变更同步到从库中,也就是写操作。即主从复制和读写分离是离不开的。
使用Sharding-JDBC完成对订单表的水平分表,通过快速入门程序的开发,快速体验Sharding-JDBC的使用。人工创建两张表,t_order_1和t_order_2,这张表是订单表替换后的表,通过Shading-JDBC向订单表插入数据,按照一定的分片规则,主键为偶数的尽入t_order_1,另一部分数据进入t_order_2,通过Shading-Jdbc查询数据,根据SQL语句的内容从t_order_1或order_2查询数据。
一般来说电商的日订单都是百千万级甚至是亿万级别的了,小小的数据库肯定是撑不住的,这时候就要提前考虑分库分表了。
一个系统最初的线上业务量并不会很大,比如说单库的数据量在百万级别以下(事实上千万级别以下都还能支撑),那么MySQL的单库即可完成任何增/删/改/查的业务操作。随着业务的发展,单个DB中保存的数据量(用户、订单、计费明细和权限规则等数据)呈现指数级增长,那么各种业务处理操作都会面临单DB的IO读写瓶颈带来的性能问题。
上一篇文章,阿粉讲了关于分库分表是怎么进行切分的,都有什么切分方式,垂直切分和水平切分,还有就是使用什么工具进行分库分表,Sharding和Mycat我们回顾一下:
有关Sharding-JDBC介绍这里就不在多说,之前Sharding-JDBC是当当网自研的关系型数据库的水平扩展框架,现在已经捐献给Apache,具体可以查看Github,地址是
本文是Sharding-JDBC采用Spring Boot Starter方式配置第二篇,第一篇是读写分离讲解,请参考:《Spring Boot中整合Sharding-JDBC读写分离示例》
因为使用我们使用Sharding-JDBC Spring Boot Starter,所以还是只需要在properties配置文件配置主从库的数据源即可
之前一篇文章中我们讲了基于Mysql8的读写分离(文后有链接),这次来说说分库分表的实现过程。
当我们的数据量比较大(没接触过)就会考虑一下分库分表的策略。当然分库分表又分为多种策略:
应用程序通过迭代器接口获取对象实例,这里首先会判断 providers 对象中是否有实例对象:
上一篇文章阿粉已经实现了数据库进行分表的操作,而且也成功了,如果有想看的,可以看一下上一天的文章,使用SpringBoot整合 Sharding-JDBC 实现了单数据库分表保存数据和查询不同表中的数据。今天我们就来实现一下分库,并且分表,然后同样的执行保存数据和查询数据的操作。
本文是《分库分表ShardingSphere5.x原理与实战》系列的第三篇文章,本文将为您介绍 ShardingSphere 的一些基础特性和架构组成,以及在 Springboot 环境下通过 JAVA编码 和 Yml配置 两种方式快速实现分库分表。
之前写过一篇使用sharding-jdbc进行分库分表的文章,https://blog.csdn.net/tianyaleixiaowu/article/details/70242971,当时的版本还比较早,现在已经不能用了。这一篇是基于最新版来写的。新版已经变成了shardingsphere了,https://shardingsphere.apache.org/。
垂直分表: 将一张宽表(字段很多的表), 按照字段的访问频次进行拆分,就是按照表单结构进行 拆。
本质上,读写分离,仅仅是多数据源的一个场景,从节点是只提供读操作的数据源。所以只要实现了多数据源的功能,也就能够提供读写分离。
进入sharding-spring-boot-mybatis-example模块,先来通过boot和mybatis整合版本整理下基本功能: 关于springboot autoconfigure部分,看下面的sharding-jdbc-spring-boot-starter的截图:
这里我只准备了一台服务器进行搭建测试,遂主库和从库均在一台服务器上,只不过是访问端口不一样而已
为了减轻每台MySQL主机的访问压力,还可以对MySQL进行读写分离,实际上,主从复制和读写分离一般就是联合使用的。
前段时间写了篇如何使用Sharding-JDBC进行分库分表的例子,相信能够感受到Sharding-JDBC的强大了,而且使用配置都非常干净。官方支持的功能还包括读写分离、分布式主键、强制路由等。这里再介绍下如何在分库分表的基础上集成读写分离的功能。
在shigen之前的文章中,写到了Springboot +mybatis plus实现读写分离,没有sharding-jdbc的夹持,真的是举步维艰啊。在接触这个神器之后,发现之前的代码很难改了,于是就在前一篇文章spring boot+sharding jdbc实现分库分表的基础上再次的修改。基础的配置这里不再展开了,需要的话可以参考之前的文章。
sharding-jdbc在目前微服务和各种saas软件等数据量日益加大的情况下变得使用的人多了起来。
其实很多人对分库分表多少都有点恐惧,其实我也是,总觉得这玩意是运维干的、数据量上来了或者sql过于复杂、一些数据分片的中间件支持的也不是很友好、配置繁琐等多种问题。
代码不多,文章可能有点长。朋友面试某厂问到的 SPI 机制,联想到自己项目最近写到的 SPI 场景,文章简要描述下 SPI 机制的发展历程
本次拆分主要包括订单和优惠券两大块,这两块都是覆盖全集团所有分子公司所有业务线。随着公司的业务飞速发展,不管是存储的要求,还是写入、读取的性都基本上到了警戒水位。
常用的主流开源数据库连接池有C3P0、DBCP、Tomcat Jdbc Pool、BoneCP、Druid等
主人公小王入职了一家刚起步的创业公司,公司正在研发一款App。为了快速开发出能够投入市场进行宣传的版本,小王可是天天加班到很晚,忙了一段时间后终于把第一个版本赶出来了。
刚插入一条数据,然后马上就要去读取,这个时候有可能会读取不到?归根到底是因为主节点写入完之后数据是要复制给从节点的,读不到的原因是复制的时间比较长,也就是说数据还没复制到从节点,你就已经去从节点读取了,肯定读不到。mysql5.7 的主从复制是多线程了,意味着速度会变快,但是不一定能保证百分百马上读取到,这个问题我们可以有两种方式解决:
上文《快速入门分库分表中间件 Sharding-JDBC (必修课)》中介绍了 sharding-jdbc 的基础概念,还搭建了一个简单的数据分片案例,但实际开发场景中要远比这复杂的多,我们会按 SQL 中会出现的不同操作符 >、<、between and、in等,来选择对应数据分片策略。
安全控制一直是治理的重要环节,数据脱敏属于安全控制的范畴。对互联网公司、传统行业来说,数据安全一直是极为重视和敏感的话题。
大家好,我是BNTang,最近又去忙其他事情去了,终于有时间来水一篇文章啦,本文给大家介绍一下如何使用 ShardingSphere + MySQL 进行分表分表,分表分库之后我们又该如何进行查询,好了废话不多说开始咯。
最初线上系统的业务量不是很大,业务数据量并不大,比如说单库的数据量在百万级别以下(事实上千万级别以下都还能支撑),那么MySQL的单库即可完成任何增/删/改/查的业务操作。随着业务的发展,单个DB中保存的数据量(用户、订单、计费明细和权限规则等数据)呈现指数级增长,那么各种业务处理操作都会面临单DB的IO读写瓶颈带来的性能问题。
书接上文 《一文快速入门分库分表(必修课)》,这篇拖了好长的时间,本来计划在一周前就该写完的,结果家庭内部突然人事调整,领导层进行权利交接,随之宣布我正式当爹,紧接着家庭地位滑落至第三名,还给我分配了一个长期维护任务:带娃。看看我们的靓照,标准的小淑女一枚萌萌哒。
互联网高速发展,同时也带来的海量数据存储问题。传统关系型数据库的单库单表已经很难支撑,如何高效存储和访问这些数据,成为业内急需解决的问题。解决思路有两个方向:
本文Java工程使用Maven搭建,基于SpringBoot框架,ORM框架使用Mybatis-Plus(建议自己先搭建下Demo工程)。
领取专属 10元无门槛券
手把手带您无忧上云