Apache ShardingSphere

Apache ShardingSphere(Incubator) 是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar（规划中）这 3 款相互独立，却又能够混合部署配合使用的产品组成。它们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。

ShardingSphere 定位为关系型数据库中间件，旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。它通过关注不变，进而抓住事物本质。关系型数据库当今依然占有巨大市场，是各个公司核心业务的基石，未来也难于撼动，我们目前阶段更加关注在原有基础上的增量，而非颠覆。Apache 官方发布从 4.0.0 版本开始。

分库分表

数据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO 等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。

分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分成若干数据库组成，将数据大表拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的。

分库分表的方式

数据库的切分指的是通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）中，以达到分散单台设备负载的效果，即分库分表。

数据的切分根据其切分规则的类型，可以分为 垂直切分 和水平切分

• 垂直切分： 把单一的表拆分成多个表，并分散到不同的数据库（主机）上
• 水平切分：根据表中数据的逻辑关系，将表中的数据按照某种条件拆分到多台数据库上

垂直切分

一个数据库有多个表构成，每个表对应不同的业务，垂直切分是只按照业务将表进行分类，将其分布到不同的数据库上，这样就将数据分担到了不同的库上（专库专用）

垂直分表

操作数据库中某张表，把这张表中一部分字段数据存到一张新表里面，再把这张表另一部分字段数据存到另外一张表里面

垂直分库

把单一数据库按照业务进行划分，专库专表

垂直切分的优点如下：

• 拆分后业务清晰，系统之间进行整合或扩展很容易。

• 按照成本、应用的等级、应用的类型等奖表放到不同的机器上，便于管理，数据维护简单。

垂直切分的缺点如下：

• 部分业务表无法关联(Join), 只能通过接口方式解决，提高了系统的复杂度。

• 受每种业务的不同限制，存在单库性能瓶颈，不易进行数据扩展和提升性能。

• 事务处理变得复杂。

水平切分

与垂直切分对比，水平切分不是将表进行分类，而是将其按照某个字段的某种规则分散到多个库中，在每个表中包含一部分数据，所有表加起来就是全量的数据。

简单来说，我们可以将对数据的水平切分理解为按照数据行进行切分，就是将表中的某些行切分到一个数据库表中，而将其他行切分到其他数据库表中。

水平分库

水平分表

水平切分的优点：

• 单库单表的数据保持在一定的量级，有助于性能的提高。

• 切分的表的结构相同，应用层改造较少，只需要增加路由规则即可。

• 提高了系统的稳定性和负载能力。

水平切分的缺点如下：

• 切分后，数据是分散的，很难利用数据库的 Join 操作，跨库 Join 性能较差。

• 分片事务的一致性难以解决，数据扩容的难度和维护量极大。

分库分表带来的问题

• 存在跨节点 Join 的问题。
• 存在跨节点合并排序、分页的问题。
• 存在多数据源管理的问题

分库分表中间件

目前，国内使用比较多的分库分表的中间件，主要有：

• Apache ShardingSphere
• Mycat

Sharding-JDBC

Sharding-JDBC 是当当网研发的开源分布式数据库中间件，从 3.0 开始 Sharding-JDBC 被包含在 Sharding-Sphere 中，之后该项目进入进入 Apache 孵化器，4.0 版本之后的 版本为 Apache 版本。

Sharding-JDBC 是 ShardingSphere 的第一个产品，也是 ShardingSphere 的前身。 它定 位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。它使用客户端直连数据库， 以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

Sharding-JDBC的核心功能为数据分片和读写分离，通过Sharding-JDBC，应用可以透明的使 用jdbc访问已经分库分表、读写分离的多个数据源，而不用关心数据源的数量以及数据如何分布。

• 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC。
• 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等。
• 支持任意实现 JDBC 规范的数据库。目前支持 MySQL，Oracle，SQLServer， PostgreSQL 以及任何遵循 SQL92 标准的数据库。

sharding-jdbc实现水平分表

spring:shardingsphere:datasource:# 配置数据源的名称names: ds1ds1:type: com.alibaba.druid.pool.DruidDataSourcedriver-class-name: com.mysql.cj.jdbc.Driverurl: jdbc:mysql://localhost:3306/cloud_user?useUnicode=true&characterEncoding=utf-8&serverTimezone=UTCusername: rootpassword: root# 打开sql输出日志props:sql:show: truesharding:tables:tb_user:# 指定tb_user表的分布情况，配置表在哪个数据库中，表名称是什么actual-data-nodes: ds1.tb_user_$->{1..2}# 指定orders表里主键id生成策略key-generator:column: idtype: SNOWFLAKE# 指定分片策略。根据id的奇偶性来判断插入到哪个表table-strategy:inline:algorithm-expression: tb_user_${id%2+1}sharding-column: id

sharding-jdbc实现水平分库

spring:shardingsphere:datasource:# 配置不同的数据源names: ds1,ds2#配置ds1数据源的基本信息ds1:driver-class-name: com.mysql.cj.jdbc.Drivertype: com.alibaba.druid.pool.DruidDataSourceurl: jdbc:mysql://localhost:3306/cloud_order?useUnicode=true&characterEncoding=utf-8&serverTimezone=UTCusername: rootpassword: root#配置ds2数据源的基本信息ds2:driver-class-name: com.mysql.cj.jdbc.Drivertype: com.alibaba.druid.pool.DruidDataSourceurl: jdbc:mysql://localhost:3306/cloud_user?useUnicode=true&characterEncoding=utf-8&serverTimezone=UTCusername: rootpassword: root#打开sql输出日志props:sql:show: truesharding:tables:tb_order:#指定数据库的分布情况actual-data-nodes: ds$->{1..2}.tb_order_$->{1..2}#指定库分片策略，根据user_id的奇偶性来添加到不同的库中database-strategy:inline:algorithm-expression: ds$->{user_id%2+1}sharding-column: user_id#指定tb_order表的主键生成策略key-generator:column: idtype: SNOWFLAKE#指定表分片策略，根据id的奇偶性来添加到不同的表中table-strategy:inline:algorithm-expression: tb_order_$->{id%2+1}sharding-column: id

sharding-jdbc实现垂直分库