Sharding-JDBC

一、概念先行 1）SQL相关的 逻辑表：水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：订单数据根据主键尾数拆分为2张表，分别是t_order_0到t_order_1，他们的逻辑表名为t_order。 真实表：在分片的数据库中真实存在的物理表。例：示例中的t_order_0到t_order_1 数据节点：数据分片的最小单元。由数据源名称和数据表组成，例：ds_0.t_order_0；ds_0.t_order_1； 绑定表：指分片规则一致的主表和子表。例如：t_order表和t_order_item表，均按照order_id分片，则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。 广播表：指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景，例如：字典表，示例中的t 2）分片相关 分片键：用于分片的数据库字段，是将数据库(表)水平拆分的关键字段。例：将订单表中的订单主键的尾数取模分片，则订单主键为分片字段。 SQL中如果无分片字段，将执行全路由，性能较差。 除了对单分片字段的支持，ShardingSphere也支持根据多个字段进行分片。 分片算法：通过分片算法将数据分片，支持通过=、>=、<=、>、<、BETWEEN和IN分片

坑一：druid 要使用spring 版本而不是spring boot 版本 <!-- alibaba druid 由于使用sharding-jdbc需要注意的是,此时druid不能用spring-boot-starter版本的,需要用正常的包:否则报找不到url --> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.1.22</version> </dependency> 坑二：sharding-jdbc 使用spring boot版本而不是spring 版本 <dependency> <groupId>org.apache.shardingsphere</groupId> <artifactId>sharding-jdbc-spring-boot-starter</artifactId> <version>4.1.1</version> </dependency> 来源： oschina 链接： https://my.oschina.net/u/4301555/blog/4404826

前言 多数据源的事务处理是个老生常谈的话题，跨两个数据源的事务管理也算是分布式事务的范畴，在同一个JVM里处理多数据源的事务，比较经典的处理方案是JTA(基于XA协议建模的java标准事务抽象)+XA(XA事务协议)，常见的JTA实现框架有Atomikos、Bitronix、Narayana，Spring对这些框架都有组件封装，基本可以做到开箱即用程度。本文除了分享XA事务方案外，提供了一种新的多数据源事务解决思路和视角。 问题背景 在解决mysql字段脱敏处理时，结合sharding-jdbc的脱敏组件功能，为了sql兼容和最小化应用改造，博主给出了一个多数据源融合的字段脱敏解决方案（只把包含脱敏字段表的操作走sharding-jdbc脱敏代理数据源）。这个方案解决了问题的同时，带来了一个新的问题，数据源的事务是独立的，正如我文中所述 《JPA项目多数据源模式整合sharding-jdbc实现数据脱敏》 ,在spring上下文中，每个数据源对应一个独立的事务管理器，默认的事务管理器的数据源就用业务本身的数据源，所以需要加密的业务使用时，需要指定@Transactional注解里的事务管理器名称为脱敏对应的事务管理器名称。简单的业务场景这样用也就没有问题了，但是一般的业务场景总有一个事务覆盖两个数据源的操作，这个时候单指定哪个事务管理器都不行，so，这里需要一种多数据源的事务管理器

一、数据库瓶颈 不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。 1、IO瓶颈 第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。 第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。 2、CPU瓶颈 第一种：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算。 第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。 二、分库分表 1、水平分库 概念： 以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。 结果： 每个库的结构都一样； 每个库的数据都不一样，没有交集； 所有库的并集是全量数据； 场景： 系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库。 分析： 库多了，io和cpu的压力自然可以成倍缓解。 2、水平分表 概念： 以字段为依据，按照一定策略（hash、range等）

数据库的数据量达到一定程度之后，为避免带来系统性能上的瓶颈，需要进行数据的处理，采用的手段是分区、分片、分库、分表。 1)分库 业务拆分 - 如顾客，商品，订单各自分独立的库 主备 - 主机做读写，备机只做数据备份 主从(读写分离) - 主机写，从机读 主主 - 任意一台机做写，互相复制 集群 - 一主多备、一主多从、多主多从，主机写，所有机都可以读 1)分片(类似分库) 分片是把数据库横向扩展（Scale Out）到多个物理节点上的一种有效的方式，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。 Shard这个词的意思是“碎片”。 如果将一个数据库当作一块大玻璃，将这块玻璃打碎，那么每一小块都称为数据库的碎片（DatabaseShard）。 将整个数据库打碎的过程就叫做分片，可以翻译为分片。 形式上，分片可以简单定义为将大数据库分布到多个物理节点上的一个分区方案。每一个分区包含数据库的某一部分，称为一个片，分区方式可以是任意的，并不局限于传统的水平分区和垂直分区。 一个分片可以包含多个表的内容甚至可以包含多个数据库实例中的内容。每个分片被放置在一个数据库服务器上。 一个数据库服务器可以处理一个或多个分片的数据。 系统中需要有服务器进行查询路由转发，负责将查询转发到包含该查询所访问数据的分片或分片集合节点上去执行。 2)分表

本文使用 Sharding-JDBC 实现读写分离，基于 CentOS 7 + MySQL 5.7 一、MySQL 安装及配置 1.1 安装 依次执行命令： sudo wget -i -c http://dev.mysql.com/get/mysql57-community-release-el7-10.noarch.rpm sudo yum -y install mysql57-community-release-el7-10.noarch.rpm sudo yum -y install mysql-community-server sudo yum -y remove mysql57-community-release-el7-10.noarch 启动： sudo systemctl start mysqld 1.2 修改密码 查看默认密码： grep "password" /var/log/mysqld.log 进入数据库： mysql -uroot -p 修改密码： alter user 'root'@'localhost' identified by 'NEW PASSWORD'; 远程访问： use mysql; grant all privileges on *.* TO 'root'@'%' identified by 'PASSWORD'; flush

sharding-sphere是强大的读写分离、分表分库中间件，sharding-jdbc是sharding-sphere的核心模块。 官方网站 springboot项目中集成sharding-jdbc也非常简单。 首先，引入sharding-jdbc和druid的jar包： <!-- for spring boot --> <dependency> <groupId>io.shardingsphere</groupId> <artifactId>sharding-jdbc-spring-boot-starter</artifactId> <version>${sharding-sphere.version}</version> </dependency> <!-- for spring namespace --> <dependency> <groupId>io.shardingsphere</groupId> <artifactId>sharding-jdbc-spring-namespace</artifactId> <version>${sharding-sphere.version}</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid<

1、什么是分库分表 就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。 2、为什么分库分表 数据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。 3、分库分表的实施策略 分库分表有垂直切分和水平切分两种。 垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立定义数据库workDB、商品数据库payDB、用户数据库userDB等，分别用于存储项目数据定义表、商品定义表、用户数据表等。 水平切分，当一个表中的数据量过大时，我们可以把该表的数据按照某种规则，例如userID散列，进行划分，然后存储到多个结构相同的表，和不同的库上。例如，我们的userDB中的用户数据表中，每一个表的数据量都很大，就可以把userDB切分为结构相同的多个userDB：part0DB、part1DB等，再将userDB上的用户数据表userTable，切分为很多userTable：userTable0、userTable1等，然后将这些表按照一定的规则存储到多个userDB上

一、遇到的问题 随着互联网技术和业务规模的发展，单个db的表里数据越来越多，sql的优化已经作用不明显或解决不了问题了，这时系统的瓶颈就是单个db了（或单table数据太大）。这时候就涉及到分库分表的问题了，很多开源解决方案来解决这个问题。比如（排名不分先后）： 当当网的 sharding-jdbc 携程的 ctripcorp 阿里的Cobar 第三方 mycat （基于Cobar） 本片主要以sharding-jdbc为例研究下分库分表的实施方案。 二、sharding-jdbc简介 Sharding-JDBC是一个开源的适用于微服务的分布式数据访问基础类库。 Sharding-JDBC定位为轻量级java框架，使用客户端直连数据库，以jar包形式提供服务，未使用中间层，无需额外部署，无其他依赖，DBA也无需改变原有的运维方式，可理解为增强版的JDBC驱动，旧代码迁移成本几乎为零。 Sharding-JDBC完整的实现了分库分表，读写分离和分布式主键功能，并初步实现了柔性事务。 性能比较，摘录自官方： 三、解决的问题 1. 分库分表 SQL解析功能完善，支持聚合，分组，排序，LIMIT，TOP等查询，并且支持级联表以及笛卡尔积的表查询 支持内、外连接查询 分片策略灵活，可支持=，BETWEEN，IN等多维度分片，也可支持多分片键共用，以及自定义分片策略

一、什么是Sharding-jdbc？ 在介绍Sharding-JDBC之前，我们需要先说明下Sharding-Sphere。 Sharding-Sphere 是一套开源的 分布式数据库中间件解决方案 组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（计划中）这3款相互独立的产品组成。他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。 1.1 Sharding-JDBC Sharding-JDBC 是一个 开源的分布式数据库中间件 ，它无需额外部署和依赖，旧代码迁移成本几乎为零。Sharding-JDBC 作为面向开发的微服务云原生基础类库，完整地实现了分库分表、读写分离和分布式主键功能，并初步实现柔性事务。 它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。 （1）适用于任何基于Java的 ORM 框架 ，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。 （2）基于任何第三方的 数据库连接池 ，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。 （3）支持任意实现JDBC