存储-海量数据（ShardingSphere核心概念剖析和实战）

目标

Ø 掌握数据库的大数据处理方案和HA
Ø 掌握为什么需要数据库中间件，何为数据库中间件
Ø 掌握不同场景所需的数据库中间件特性
Ø 掌握数据库中间件设计要点

 

Sharding-JDBC用途、使用场景、架构

认识ShardingSphere

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

当前版本：3.0
官网地址：https://shardingsphere.apache.org/index_zh.html
官方文档：https://shardingsphere.apache.org/document/current/cn/overview/

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

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

Sharding-JDBC功能架构图

认识Sharding-Proxy

Sharding-Proxy：定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本， 用于完成对异构语言的支持。 目前先提供MySQL版本，它可以使用任何兼容MySQL协议的访问 客户端(如：MySQL Command Client, MySQL Workbench等)操作数据，对DBA更加友好。

Ø 向应用程序完全透明，可直接当做MySQL使用。
Ø 适用于任何兼容MySQL协议的客户端。

认识Sharding-Proxy功能架构图

三个组件对比认识

 

混合架构

Sharding-JDBC采用无中心化架构，适用于Java开发的高性能的轻量级OLTP应用；Sharding-Proxy提供静态入口 以及异构语言的支持，适用于OLAP应用以及对分片数据库进行管理和运维的场景。

ShardingSphere功能清单

数据分片：

Ø 分库 & 分表
Ø 读写分离
Ø 分布式主键

分布式事务（doing）：

Ø XA强一致事务
Ø 柔性事务

数据库治理：

Ø 配置动态化
Ø 熔断 & 禁用
Ø 调用链路追踪
Ø 弹性伸缩 (Planning)

ShardingSphere数据分片内核工作原理

ShardingSphere的3个产品的数据分片主要流程是完全一致的 核心由SQL解析 => 执行器优化 => SQL路由 => SQL改写 => SQL执行 => 结果归并的流程组成

规划路线图

Sharding-JDBC配置使用

Sharding 课程小结- JDBC入门使用

Sharding-JDBC使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强 版的JDBC驱动，完全兼容JDBC和各种ORM框架。

内容参考：Sharding-JDBC入门使用.pdf

 

Sharding-JDBC分库分表实战

Sharding-JDBC分库分表概念

逻辑表

水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：订单数据根据主键%2拆分为2张表，分 别是t_order0、t_order1，他们的逻辑表名为t_order。

Sharding-JDBC分库分表概念-数据节点

Sharding-JDBC分库分表概念-分片策略

数据源分片、表分片仅是两个不同维度的分片，它们能用的分片策略规则是一样的。 Sharding-JDBC中提供了常用的分片策略实现。分片策略由两部分构成：

Ø 分片键
Ø 分片算法

Sharding-JDBC提供的5种分片策略

none 不分片策略

对应NoneShardingStrategy ，不分片策略 ,SQL会被发给所有节点去执行,这个规则没有子项目可以配置。

inline 行表达式分片策略  必掌握

对应InlineShardingStrategy。使用Groovy的表达式，提供对SQL语句中的=和IN的分片操作支持，只支 持单分片键。对于简单的分片算法，可以通过简单的配置使用，从而避免繁琐的Java代码开发，如: t_user_$->{u_id % 8} 表示t_user表根据u_id模8，而分成8张表，表名称为t_user_0到t_user_7。

databaseStrategy:
  inline:
  shardingColumn: user_id
  algorithmInlineExpression: ds${user_id % 2}

行表达式语法

Ø ${begin..end}表示范围区间
Ø ${[unit1, unit2, unit_x]}表示枚举值
Ø 行表达式中如果出现连续多个${ expression }或$->{ expression }表达式，整个表达式最终的结果将会根据每个子表达式的结果进行笛卡尔组合。

standard 标准分片策略  需了解

Ø 对应StandardShardingStrategy。提供对SQL语句中的=, IN和BETWEEN AND的分片操作支持。
Ø StandardShardingStrategy只支持单分片键，提供PreciseShardingAlgorithm和RangeShardingAlgorithm两个分片算法。
Ø PreciseShardingAlgorithm是必选的，用于处理=和IN的分片。
Ø RangeShardingAlgorithm是可选的，用于处理BETWEEN AND分片，如果不配置RangeShardingAlgorithm，SQL中的BETWEEN AND将按照全库路由处理。

databaseStrategy:
  standard: #单列sharidng算法,需要配合对应的preciseShardingAlgorithm,rangeShardingAlgorithm接口的实现使用
  shardingColumn: # 列名,允许单列
  preciseShardingAlgorithm: # preciseShardingAlgorithm接口的实现类
  rangeShardingAlgorithm: # rangeShardingAlgorithm接口的实现类

complex 复合分片策略 需了解

Ø 对应ComplexShardingStrategy。复合分片策略提供对SQL语句中的=, IN和BETWEEN AND的分片操作支持。
Ø ComplexShardingStrategy支持多分片键，由于多分片键之间的关系复杂，因此并未进行过多的封装，而是直接将分片键值组合以及分片操作符透传至分片算法，完全由应用开发者实现，提供最大的灵活度。

hint分片策略 需了解

Ø 对应HintShardingStrategy。通过Hint而非SQL解析的方式分片的策略。
Ø 对于分片字段非SQL决定，而由其他外置条件决定的场景，可使用SQL Hint灵活的注入分片字段。例：内部系统，按照员工登录主键分库，而数据库中并无此字段。SQL Hint支持通过Java API和SQL注释(待实现)两种方式使用。

databaseStrategy:
  hint: #基于标记的sharding分片
    shardingAlgorithm: # 需要是HintShardingAlgorithm接口的实现,目前代码中,有为测试目的实现的OrderDatabaseHintShardingAlgorithm可参考

Sharding-JDBC配置默认数据源、分片策略

可配置默认的数据源、数据源分片策略、表分片策略 需了解

Sharding-JDBC—分布式主键

分布式主键

ShardingSphere提供灵活的配置分布式主键生成策略方式。 在分片规则配置模块可配置每个表的主键生成策略，默认使用雪花算法（snowflake）生成64bit的长整型数据。
当前提供了 SNOWFLAKE、UUID 两种可用方式。

Sharding-JDBC分库分表概念-绑定表

绑定表

指分片规则一致的主表和子表。例如：t_order表和t_order_item表，均按照order_id分片，则此两张表互 为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。

Sharding-JDBC分库分表概念-绑定表示例

如果SQL为

SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

在不配置绑定表关系时，假设分片键order_id将数值10路由至第0片，将数值11路由至第1片，那 么路由后的SQL应该为4条，它们呈现为笛卡尔积：

 SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
 SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
 SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
 SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

在配置绑定表关系后，路由的SQL应该为2条：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

其中t_order在FROM的最左侧，ShardingSphere将会以它作为整个绑定表的主表。 所有路由计算将会只使用主表的策略， 那么t_order_item表的分片计算将会使用t_order的条件。故绑定表之间的分区键要完全相同。

Sharding-JDBC分库分表概念-广播表

广播表

指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。适用于数 据量不大且需要与海量数据的表进行关联查询的场景，例如：字典表。

shardingRule:
  broadcastTables:
    - t_config

 

Sharding-JDBC事务应用与数据治理

Sharding-JDBC-分布式事务应用

Spring-boot-starter 方式

<dependency>
 <groupId>io.shardingsphere</groupId>
 <artifactId>sharding-transaction-spring-boot-starter</artifactId>
 <version>${sharding-sphere.version}</version>
</dependency>

业务代码中应用

@ShardingTransactionType(TransactionType.LOCAL)
@Transactional

@ShardingTransactionType(TransactionType.XA)
@Transactional

注意：@ShardingTransactionType需要同Spring的@Transactional配套使用，事务才会生效。

Atomikos参数配置

ShardingSphere默认的XA事务管理器为Atomikos。 可以通过在项目的classpath中添加jta.properties 来定制化Atomikos配置项。 具体的配置规则请参考Atomikos的官方文档。

Sharding-JDBC-数据治理-配置中心

实现动机

Ø 配置集中心化：越来越多的运行时实例，使得散落的配置难于管理，配置不同步导致的问题分严重。将配置集中于配置中心，可以更加有效进行管理。
Ø 配置动态化：配置修改后的分发，是配置中心可以提供的另一个重要能力。它可支持数据源、表与分片及读写分离策略的动态切换。

参考链接： https://shardingsphere.apache.org/document/current/cn/manual/shardingjdbc/usage/orchestration/

 

 

 

来源：https://my.oschina.net/u/3728166/blog/3138455