【无标题】

ShardingSphere 分库分表技术实践

一、简介

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

今天给大家主要讲解的说ShardingJdbc应用，先简单介绍下ShardingSphere 两种主要分片应用及场景：
1、垂直分片：
按照业务维度将表拆分到不同的数据库，专库专用，分担数据库压力

白话简介：一张表不是有很多列字段，垂直拆分就是把字段拆出来呗，那怎么拆字段呢，当然是同一维度的拆出来。比如一个订单表。里面的订单相关字段能不能放到订单库的表里，里面的商品字段能不能放商品库的表里，里面的地址信息能不能放用户信息库里。

2、水平分片
按照某种规则将单表数据拆分到多张表中，突破了单机数据量的瓶颈。水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案。

白话介绍：一张表随着时间的推移，数据越来越多，查的越来越慢，那么就得横向将行拆出来，横向拆行就是水平分片。比如按订单号单双来拆。

接下来：
（今天主要演示的是常用的水平分片模式，演示前先介绍下数据分片的5种核心概念，如下述二模块：）

二、核心概念及实现

核心概念分为以下5部分
1、逻辑表
水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：客户信息表分为user_info1,user_info2 2张表，他们的逻辑表名为user_info。（配置文件展示）

2、真实表
在分片的数据库中真实存在的物理表，即user_info1,user_info2。（数据库表展示）

3、数据节点
数据分片的最小单元。由数据源名称和数据表组成，例：ds_0.user_info_0。（配置文件展示）

4、绑定表
指分片规则一致的主表和子表。例如：orders表和orders_items表，均按照order_no分片，则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。
其中orders在FROM的最左侧，ShardingSphere将会以它作为整个绑定表的主表。 所有路由计算将会只使用主表的策略，那么orders_items表的分片计算将会使用orders的条件。故绑定表之间的分区键要完全相同。（代码举例说明）

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

三、水平分片常用的分片策略

1.取模分片：
优点：数据存放均匀
缺点：假设取模值更改进行扩容，那么更改后，原表中的某些数据就需要迁移到新表中，迁移数据量大**（演示取模分表）**

2.范围分片：比如按时间进行分片，一月的放个表，二月的放个表
优点：增加分片不会引起大面积数据迁移
缺点：可能会导致分片数据倾斜，比如双十一的时候，11月这个表的数据量就会很大。（暂不演示）

四、分布式事务

1、两阶段事务-XA
功能
支持数据分片后的跨库XA事务
两阶段提交保证操作的原子性和数据的强一致性
服务宕机重启后，提交/回滚中的事务可自动恢复
（代码演示跨库事务）

五、FAQ
1、如果只有部分数据库分库分表，是否需要将不分库分表的表也配置在分片规则中？

答案：是。因为ShardingSphere是将多个数据源合并为一个统一的逻辑数据源。因此即使不分库分表的部分，不配置分片规则ShardingSphere即无法精确的断定应该路由至哪个数据源。 但是ShardingSphere提供了两种变通的方式，有助于简化配置。

方法1：配置default-data-source，凡是在默认数据源中的表可以无需配置在分片规则中，ShardingSphere将在找不到分片数据源的情况下将表路由至默认数据源。

方法2：将不参与分库分表的数据源独立于ShardingSphere之外，在应用中使用多个数据源分别处理分片和不分片的情况。

2、sum方法里，当包含ifnull（sum)，且条件未含分片键，或者采用范围查询时跨库跨表里，会出现，本该获取出来应该说一条汇总数据，但实际会出现多条（执行了几个sql则得到对应的几条）（代码演示）。