【ShardingSphere 技术专题】「ShardingJDBC」（1）带你一同认识一下 ShardingJDBC 是什么？（高手勿入）

ShardingJDBC 的背景介绍

目前存在的痛点

• 业务场景：传统数据存储方式采用单一数据节点的解决方案，在性能、可用性和运维成本这三方面已经难于满足互联网的海量数据场景。

• 性能方面：由于关系型数据库大多采用 B+ 树类型的索引，【在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的 IO 次数增加，进而导致查询性能的下降】，同时，【高并发访问请求也使得集中式数据库成为系统的最大瓶颈】。

• 可用性方面：服务化的无状态型，能够达到较小成本的随意扩容，这必然导致系统的最终压力都落在数据库之上。而单一的数据节点，或者简单的主从架构，已经越来越难以承担。数据库的可用性，已成为整个系统的关键。

• 运维成本：当一个数据库实例中的数据达到阈值以上，对于 DBA 的运维压力就会增大。数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。一般来讲，单一数据库实例的数据的阈值在 1TB 之内，是比较合理的范围。

• 技术方面：将数据存储至原生支持分布式的 NoSQL 的尝试越来越多，但是 NoSQL、NewSQL 的发展仍然还不成熟！

ShardingJDBC 的适用范围

• 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC。

• 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等。

• 支持任意实现 JDBC 规范的数据库，目前支持 MySQL，Oracle，SQLServer，PostgreSQL 以及任何遵循 SQL92 标准的数据库。

ShardingJDBC 的定位及场景

• ShardingJDBC 被定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

• 它属于透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。

目前提供 MySQL 和 PostgreSQL（兼容 openGauss 等基于 PostgreSQL 的数据库）版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端（如：MySQL Command Client, MySQL Workbench, Navicat 等）操作数据，对 DBA 更加友好。

• 向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用。

• 适用于任何兼容 MySQL/PostgreSQL 协议的的客户端。

ShardingJDBC 的技术方向

通过分库和分表进行数据的拆分来使得各个表的数据量保持在阈值以下，以及对流量进行疏导应对高访问量，是应对高并发和海量数据系统的有效手段。

数据分片技术

• 数据分片指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可用性的效果。

• 数据分片的有效手段是对关系型数据库进行分库和分表，分库和分表均可以有效的避免由数据量超过可承受阈值而产生的查询瓶颈。

分片（数据库层面分片）

分库还能够用于有效的分散对数据库单点的访问量；

分片（数据表层面分片）

分表虽然无法缓解数据库压力，但却能够提供尽量将分布式事务转化为本地事务的可能，一旦涉及到跨库的更新操作，分布式事务往往会使问题变得复杂。使用多主多从的分片方式，可以有效的避免数据单点，从而提升数据架构的可用性。

分片的拆分方式

数据分片的拆分方式又分为垂直分片和水平分片。

垂直分片

按照业务拆分的方式称为垂直分片，又称为纵向拆分，它的核心理念是专库专用。 在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则是按照业务将表、字段进行归类，分布到不同的数据库、数据表，从而将压力分散至不同的数据库（数据表）。

垂直分片存在的问题

• 垂直拆分可以缓解数据量和访问量带来的问题，但无法根治。如果垂直拆分之后，表中的数据量依然超过单节点所能承载的阈值，则需要水平分片来进一步处理。

• 垂直分片往往需要对架构和设计进行调整。来不及应对互联网业务需求快速变化的；而且，它也并无法真正的解决单点瓶颈。

水平分片

水平分片又称为横向拆分。 相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。 例如：根据主键分片，偶数主键的记录放入 0 库（或表），奇数主键的记录放入 1 库（或表）。

ShardingJDBC 做了什么

尽量透明化分库分表所带来的影响，让使用方尽量像使用一个数据库一样使用水平分片之后的数据库集群，是 Apache ShardingSphere 数据分片模块的主要设计目标。

ShardingJDBC 的使用介绍

引入 maven 依赖

<dependency>    <groupId>org.apache.shardingsphere</groupId>    <artifactId>shardingsphere-jdbc-core</artifactId>    <version>${更改为实际的版本号}</version></dependency>

支持的配置方式

• 4 种方式进行配置，开发者可根据场景选择适合的配置方式：

• Java Config

• YAML 文件配置

• Spring xml 方式

• Spring Boot Starter

ShardingJDBC 的核心组件介绍

ShardingJDBC 数据源

• ShardingJDBC 数据源是独立于我们系统内部的数据源，相当于对系统数据源做了层封装机制，主要是通过 ShardingSphereDataSourceFactory 工厂和规则配置对象获取 ShardingSphereDataSource。

• 该对象实现自 JDBC 的标准 DataSource 接口，可用于原生 JDBC 开发，或使用 JPA, MyBatis 等 ORM 类库。

DataSource dataSource = ShardingSphereDataSourceFactory.createDataSource(dataSourceMap, configurations, properties);

• dataSourceMap：代表传入进去的数据源集合信息，用于走分片的数据源集合信息，key 为不同的 datasource 名称

• configurations：代表的是相关的分片算法以及分片机制的配置核心信息

• properties：代表配置的相关定制化属性信息以及相关的 shardingjdbc 的属性信息