Sharding-JDBC

shardingsphere组成 ： sharding-jdbc 、sharding-proxy、sharding-sidecar(计划中) 核心功能以及整体框架图 sharding-jdbc特点 1. 轻量级Java框架，在Java的JDBC层提供额外服务 2.适用于任何基于JDBC的ORM框架 3.支持任何第三方数据库连接池 4.支持任意实现JDBC规范的数据库 sharding-Proxy 1.透明的数据库代理端，目前支持MYSQL/PostgreSQL 2.兼容MYSQL/PostgreSQL协议的客户端 sharding-sidecar(计划中) 1.k8s的云原生数据库代理，以Sidecar的形式代理所有对数据库的访问。通过无中心，零侵入的方案与数据库交互，称为数据网格 混合架构 1.sharding-jdbc采用无中心化架构，适用于Java开发的高性能的轻量级OLTP应用 2.Sharding-proxy提供对数据库管理和运维 3.采用统一注册中心统一配置分片策略 来源： oschina 链接： https://my.oschina.net/u/1017791/blog/3173943

转自：学习Java的小姐姐 www.cnblogs.com/chenchen0618/p/11624480.html 1.什么是分库分表 从字面上简单理解，就是将原本存储在一个库的数据分块存储在多个库上，将原本存储在一个表的数据分块存储在多个表里面。 数据的切分根据其切分规则的类型，可以分为如下两种切分模式。 垂直（纵向）切分 ：把单一的表拆分成多个表，并分散到不同的数据库（主机）上。 比如一个订单表里面有用户信息，商品信息，收货地址信息，促销信息，这样表的字段太多，显得特别臃肿，所以我们将他们各自分隔出来，形成多张表存储数据。 优点： 拆分后业务清晰，拆分规则明确。 系统之间进行整合或扩展很容易。 按照成本、应用的等级、应用的类型等将表放到不同的机器上，便于管理。 数据维护简单。 缺点： 业务表多样，SQL语句复杂。 水平（横向）切分 ：根据表中数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上。与垂直切分对比，水平切分不是将表进行分类，而是将其按照某个字段的某种规则分散到多个库中，在每个表中包含一部分数据，所有表加起来就是全量的数据。 比如有一个用户表，单张表的记录条数达到1亿条，这样在进行查询，插入，更新操作的时候，速度将非常慢，那我们可以将这些数据分配到100个表里面，每个表的数据量就下来了，导致单表的容量不会太大，从而保证了单表的查询等处理能力。

1. sharding sphere 4.0.0-RC1版本 按年分表（后续优化） 1.1. 概述 关于上一篇中 LogShardingAlgorithm 的 tables ，我原先是在第一次调用的时候初始化，这样做虽然能实现功能，但每次调用都会走这个if判断，虽然性能损耗不大，但我觉得这不是业务应该走的逻辑顺序，我的理想是在 LogShardingAlgorithm 被实例化后去自动初始化 tables 现在面对的问题是 LogShardingAlgorithm 的实例化是在Spring初始化中间执行的，且它本身的创建不是通过Spring的 @Component 等注解生成，而是通过反射实例化。若在实例化刚开始，也就是构造方法执行的时候执行初始化，那时候 applicationContext 还没有初始化完毕，拿不到环境参数，连 Datasource 也还没开始初始化 1.2. 解决方法 经过改造后，代码如下，单独拎出一个初始化方法，在类对象实例化后调用 /** * @author: laoliangliang * @description: 日志分片 * @create: 2020/1/2 10:19 **/ @Slf4j public class LogShardingAlgorithm implements PreciseShardingAlgorithm,

引言 微服务、分布式大行其道的当下，中、高级Java工程师面试题中高并发、大数据量、分库分表等已经成了面试的高频词汇，这些知识不了解面试通过率不会太高。你可以不会用，但你不能不知道，就是这么一种现状。技术名词大多晦涩难懂，不要死记硬背理解最重要，当你捅破那层窗户纸，发现其实它也就 那么回事。 一、为什么要分库分表 关系型数据库以MySQL为例，单机的存储能力、连接数是有限的，它自身就很容易会成为系统的瓶颈。当单表数据量在百万以里时，我们还可以通过添加从库、优化索引提升性能。一旦数据量朝着千万以上趋势增长，再怎么优化数据库，很多操作性能仍下降严重。为了减少数据库的负担，提升数据库响应速度，缩短查询时间，这时候就需要进行 分库分表 。 二、如何分库分表 分库分表就是要将大量数据分散到多个数据库中，使每个数据库中数据量小响应速度快，以此来提升数据库整体性能。核心理念就是对数据进行切分（ Sharding ），以及切分后如何对数据的快速定位与整合。针对数据切分类型，大致可以分为：垂直（纵向）切分和水平（横向）切分两种。 1、垂直切分 垂直切分又细分为 垂直分库 和 垂直分表 垂直分库 垂直分库是基于业务分类的，和我们常听到的微服务治理观念很相似，每一个独立的服务都拥有自己的数据库，需要不同业务的数据需接口调用。而垂直分库也是按照业务分类进行划分，每个业务有独立数 据库，这个比较好理解。

问题描述 最近公司搭建springboot项目 由于之前都是使用的spring项目 对于boot的理解还是不深 通过找一些文档搭建好了shardingJdbc分库分表的配置 使用了properties方式 参考官网配置如下 我们项目数据源使用了HikariCP 由于要对于数据连接池进行配置 方便出现问题调优 网上翻遍了配置整合 都是只有springboot初始的Hikari配置 与sharding整合的配置没有涉及到 传统springboot单数据源数据源整合配置 由于使用了分库分表 数据源前缀不同 肯定不能使用之前的配置方式 自己依样画葫芦写了点配置 发现竟然生效了 sharding.jdbc.datasource.ds0.pool-name=Retail_HikariCP0 sharding.jdbc.datasource.ds0.maximum-pool-size = 20 控制台出现了新的cpName！！ 这就让我燃起了希望 同时又找到了 https://www.cnblogs.com/aut-lory/p/10789573.html 这篇博主的文章 让我下定决心动手debug源码 查看我的配置是否生效 以及到底什么样的前缀配置才会被sharding发现并且注入 问题解决 数据源是spring初始化配置时加载的 很容易联想到spring-shardingjdbc

一、为什么要分库分表 软件时代，传统应用都有这样一个特点：访问量、数据量都比较小，单库单表都完全可以支撑整个业务。随着互联网的发展和用户规模的迅速扩大，对系统的要求也越来越高。因此传统的MySQL单库单表架构的性能问题就暴露出来了。而有下面几个因素会影响数据库性能: 数据量 MySQL单库数据量在5000万以内性能比较好，超过阈值后性能会随着数据量的增大而变弱。MySQL单表的数据量是500w-1000w之间性能比较好，超过1000w性能也会下降。 磁盘 因为单个服务的磁盘空间是有限制的，如果并发压力下，所有的请求都访问同一个节点，肯定会对磁盘IO造成非常大的影响。 数据库连接 数据库连接是非常稀少的资源，如果一个库里既有用户、商品、订单相关的数据，当海量用户同时操作时，数据库连接就很可能成为瓶颈。 为了提升性能，所以我们必须要解决上述几个问题，那就有必要引进分库分表，当然除了分库分表，还有别的解决方案，就是NoSQL和NewSQL，NoSQL主要是MongoDB等，NewSQL则以TiDB为代表。 二、分区分库分表的原理 1、什么是分区、分表、分库 （1）分区 就是把一张表的数据分成N个区块，在逻辑上看最终只是一张表，但底层是由N个物理区块组成的，分区实现比较简单，数据库mysql、oracle等很容易就可支持。 （2）分表

教学视频：https://edu.csdn.net/course/detail/26238/325885 一，简介 定位为轻量级Java框架，在Java的JDBC层提供的额外服务。 它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。 适用于任何基于JDBC的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。 支持任意实现JDBC规范的数据库。目前支持MySQL，Oracle，SQLServer，PostgreSQL以及任何遵循SQL92标准的数据库。 核心概念 1.SQL 逻辑表 水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：订单数据根据主键尾数拆分为10张表，分别是 t_order_0 到 t_order_9 ，他们的逻辑表名为 t_order 。 真实表 在分片的数据库中真实存在的物理表。即上个示例中的 t_order_0 到 t_order_9 。 数据节点 数据分片的最小单元。由数据源名称和数据表组成，例： ds_0.t_order_0 。 绑定表 指分片规则一致的主表和子表。例如： t_order

一般对于业务记录类随时间会不断增加的数据，当数据量增加到一定量（一般认为整型值为主的表达到千万级，字符串为主的表达到五百万）的时候，性能将遇到瓶颈，同时调整表结构也会变得非常困难。为了避免生产遇到这样的问题，在做系统设计时需要预估可能产生的数据量：预估记录主体个数*预估记录主体产生的记录数（e.g.用户订单表预估数据量=预估用户数*单用户产生订单数），预估达到一定量时，就不得不考虑分库分表了，目前国内比较成熟的开源数据库中间件有sharding-jdbc、mycat；而drds是阿里云最近推出的商业产品，考虑到大部分公司都在使用阿里云，做一个全家桶，也是一个不错的选择。接下来将对这三款产品的优缺点及适用场景做以介绍。 可以看出sharding-jdbc作为一个组件集成在应用内，而mycat则作为一个独立的应用需要单独部署，drds则是阿里云的一个独立产品，不过需要结合rds一起使用。从架构上看sharding-jdbc更符合分布式架构的设计，直连数据库，没有中间应用，理论性能是最高的（实际性能需要结合具体的代码实现，理论性能可以理解为上限，通过不断优化代码实现，逐渐接近理论性能）。同时缺点也很明显，由于作为组件存在，需要集成在应用内，意味着作为使用方，必须要集成到代码里，使得开发成本相对较高；另一方面，由于需要集成在应用内，使得需要针对不同语言（java、C、PHP……

一、为什么要分库分表 软件时代，传统应用都有这样一个特点：访问量、数据量都比较小，单库单表都完全可以支撑整个业务。随着互联网的发展和用户规模的迅速扩大，对系统的要求也越来越高。因此传统的MySQL单库单表架构的性能问题就暴露出来了。而有下面几个因素会影响数据库性能: 数据量 MySQL单库数据量在5000万以内性能比较好，超过阈值后性能会随着数据量的增大而变弱。MySQL单表的数据量是500w-1000w之间性能比较好，超过1000w性能也会下降。 磁盘 因为单个服务的磁盘空间是有限制的，如果并发压力下，所有的请求都访问同一个节点，肯定会对磁盘IO造成非常大的影响。 数据库连接 数据库连接是非常稀少的资源，如果一个库里既有用户、商品、订单相关的数据，当海量用户同时操作时，数据库连接就很可能成为瓶颈。 为了提升性能，所以我们必须要解决上述几个问题，那就有必要引进分库分表，当然除了分库分表，还有别的解决方案，就是NoSQL和NewSQL，NoSQL主要是MongoDB等，NewSQL则以TiDB为代表。 二、分区分库分表的原理 1、什么是分区、分表、分库 （1）分区 就是把一张表的数据分成N个区块，在逻辑上看最终只是一张表，但底层是由N个物理区块组成的，分区实现比较简单，数据库mysql、oracle等很容易就可支持。 （2）分表

原帖地址：https://blog.csdn.net/yanyan19880509/article/details/78170233 前言 很多时候，为了应付DB的高并发读写，我们会采用读写分离技术。读写分离指的是利用数据库主从技术（把数据复制到多个节点中），分散读多个库以支持高并发的读，而写只在master库上。DB的主从技术只负责对数据进行复制和同步，而读写分离技术需要业务应用自身去实现。sharding-jdbc通过简单的开发，可以方便的实现读写分离技术。本篇主要介绍其实现的原理。 sharding-jdbc读写分离特性说明 sharding-jdbc官方对其支持的读写分离技术进行了说明： 支持项 提供了一主多从的读写分离配置，可独立使用，也可配合分库分表使用。 同个调用线程，执行多条语句，其中一旦发现有非读操作，后续所有读操作均从主库读取。 Spring命名空间。 基于Hint的强制主库路由。 不支持范围 主库和从库的数据同步。 主库和从库的数据同步延迟导致的数据不一致。 主库双写或多写。 简单说明 sharding-jdbc实现读写分离技术的思路比较简洁，不支持类似主库双写或多写这样的特性，但目前来看，已经可以满足一般的业务需求了。 读写分离实现demo 库和表的设计结构如下： 简单的java代码示例： public final class MasterSlaveMain