为什么要分库分表

• 用户请求量太大

• 单库数据量太大

• 单表数据量太大

拆分方式

垂直拆分

• 垂直分库

• 垂直分表

水平拆分

• 水平分库

• 水平分库规则

• 水平分表

• 水平分表规则

面临的问题

由于数据存储在不同的库和表中，也带来了其他方面的一些问题，如下：

• ID主键怎么生成？
• 数据怎么保持一致？
• 数据库怎么扩容？
• 业务层代码怎么改造？

分页排序、事务问题、跨表跨库join问题等。

解决方案

主键选择

数据一致性

数据库扩容

业务层改造

跨库跨表join问题

中间件之ShardingSphere

简介

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

ShardingSphere定位为关系型数据库中间件，旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。

Sharding-JDBC：被定位为轻量级Java框架，在Java的JDBC层提供的额外服务，以jar包形式使用。

Sharding-Proxy：被定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。

Sharding-Sidecar：被定位为Kubernetes或Mesos的云原生数据库代理，以DaemonSet的形式代理所有对数据库的访问。

Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar三者区别如下：

Sharding-JDBC

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-JDBC 使用过程

• 引入maven依赖

<dependency> 
  <groupId>org.apache.shardingsphere</groupId> 
  <artifactId>sharding-jdbc-core</artifactId> 
  <version>${latest.release.version}</version> 
</dependency> 

• 规则配置

• 创建DataSource

DataSource dataSource = ShardingDataSourceFactory.createDataSource(dataSourceMap, 
shardingRuleConfig, props);

数据分片

核心概念

表概念

• 真实表

• 逻辑表

• 数据节点

• 绑定表

b_order：b_order0、b_order1 
b_order_item：b_order_item0、b_order_item1 

select * from b_order o join b_order_item i on(o.order_id=i.order_id) 
where o.order_id in (10,11);

如果不配置绑定表关系，采用笛卡尔积关联，会生成4个SQL

select * from b_order0 o join b_order_item0 i on(o.order_id=i.order_id) 
where o.order_id in (10,11); 

select * from b_order0 o join b_order_item1 i on(o.order_id=i.order_id) 
where o.order_id in (10,11); 

select * from b_order1 o join b_order_item0 i on(o.order_id=i.order_id) 
where o.order_id in (10,11); 

select * from b_order1 o join b_order_item1 i on(o.order_id=i.order_id) 
where o.order_id in (10,11);

如果配置绑定表关系，生成2个SQL

select * from b_order0 o join b_order_item0 i on(o.order_id=i.order_id) 
where o.order_id in (10,11); 

select * from b_order1 o join b_order_item1 i on(o.order_id=i.order_id) 
where o.order_id in (10,11);

• 广播表

• 逻辑索引

分片键

用于分片的数据库字段，是将数据库(表)水平拆分的关键字段。例：将订单表中的订单主键的尾数取模分片，则订单主键为分片字段。 SQL中如果无分片字段，将执行全路由，性能较差。 除了对单分片字段的支持，ShardingSphere也支持根据多个字段进行分片。

分片算法（ShardingAlgorithm）

通过分片算法将数据分片，支持通过=、BETWEEN和IN分片。

目前提供4种分片算法。由于分片算法和业务实现紧密相关，因此并未提供内置分片算法，而是通过分片策略将各种场景提炼出来，提供更高层级的抽象，并提供接口让应用开发者自行实现分片算法。

• 精确分片算法

• 范围分片算法

• 复合分片算法

• Hint分片算法

分片策略

包含分片键和分片算法，由于分片算法的独立性，将其独立抽离。真正可用于分片操作的是分片键 + 分片算法，也就是分片策略。目前提供5种分片策略。

• 标准分片策略

• 复合分片策略

• 行表达式分片策略

• Hint分片策略

• 不分片策略

分片策略配置

对于分片策略存有数据源分片策略和表分片策略两种维度，两种策略的API完全相同。

• 数据源分片策略

• 表分片策略

流程剖析

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

• SQL解析

• 执行器优化

• SQL路由

• SQL改写

• SQL执行

• 结果归并

SQL使用规范

支持项

路由至单数据节点时，目前MySQL数据库100%全兼容，其他数据库完善中。

路由至多数据节点时，全面支持DQL、DML、DDL、DCL、TCL。支持分页、去重、排序、分组、聚合、关联查询（不支持跨库关联）。

• SELECT主语句

SELECT select_expr [, select_expr ...] FROM table_reference [, table_reference ...]
[WHERE where_condition] 
[GROUP BY {col_name | position} [ASC | DESC]] 
[ORDER BY {col_name | position} [ASC | DESC], ...] 
[LIMIT {[offset,] row_count | row_count OFFSET offset}]

• select_expr

* | 
[DISTINCT] COLUMN_NAME [AS] [alias] | 
(MAX | MIN | SUM | AVG)(COLUMN_NAME | alias) [AS] [alias] | 
COUNT(* | COLUMN_NAME | alias) [AS] [alias]

• table_reference

tbl_name [AS] alias] [index_hint_list] | 
table_reference ([INNER] | {LEFT|RIGHT} [OUTER]) JOIN table_factor [JOIN ON conditional_expr | USING (column_list)] | 

不支持项

• 支持分页子查询，但其他子查询有限支持，无论嵌套多少层，只能解析至第一个包含数据表的子查询，一旦在下层嵌套中再次找到包含数据表的子查询将直接抛出解析异常。

例如，以下子查询可以支持：

SELECT COUNT(*) FROM (SELECT * FROM b_order o) 

以下子查询不支持：

SELECT COUNT(*) FROM (SELECT * FROM b_order o WHERE o.id IN (SELECT id 
FROM b_order WHERE status = ?)) 

简单来说，通过子查询进行非功能需求，在大部分情况下是可以支持的。比如分页、统计总数等；而通过子查询实现业务查询当前并不能支持。

• 由于归并的限制，子查询中包含聚合函数目前无法支持。
• 不支持包含schema的SQL。因为ShardingSphere的理念是像使用一个数据源一样使用多数据源，因此对SQL的访问都是在同一个逻辑schema之上。

• 当分片键处于运算表达式或函数中的SQL时，将采用全路由的形式获取结果。

例如下面SQL，create_time为分片键：

SELECT * FROM b_order WHERE to_date(create_time, 'yyyy-mm-dd') = '2020-05-05';

由于ShardingSphere只能通过SQL字面提取用于分片的值，因此当分片键处于运算表达式或函数中时，ShardingSphere无法提前获取分片键位于数据库中的值，从而无法计算出真正的分片值。

分页查询

完全支持MySQL和Oracle的分页查询，SQLServer由于分页查询较为复杂，仅部分支持.

• 性能瓶颈

查询偏移量过大的分页会导致数据库获取数据性能低下，以MySQL为例：

SELECT * FROM b_order ORDER BY id LIMIT 1000000, 10 

这句SQL会使得MySQL在无法利用索引的情况下跳过1000000条记录后，再获取10条记录，其性能可想而知。 而在分库分表的情况下（假设分为2个库），为了保证数据的正确性，SQL会改写为：

SELECT * FROM b_order ORDER BY id LIMIT 0, 1000010 

即将偏移量前的记录全部取出，并仅获取排序后的最后10条记录。这会在数据库本身就执行很慢的情况下，进一步加剧性能瓶颈。 因为原SQL仅需要传输10条记录至客户端，而改写之后的SQL则会传输1,000,010 * 2的记录至客户端。

• ShardingSphere的优化

ShardingSphere进行了以下2个方面的优化。

• 分页方案优化

由于LIMIT并不能通过索引查询数据，因此如果可以保证ID的连续性，通过ID进行分页是比较好的解决方案：

SELECT * FROM b_order WHERE id > 1000000 AND id <= 1000010 ORDER BY id 

或通过记录上次查询结果的最后一条记录的ID进行下一页的查询

SELECT * FROM b_order WHERE id > 1000000 LIMIT 10

其它功能

• Inline行表达式

InlineShardingStrategy：采用Inline行表达式进行分片的配置。

Inline是可以简化数据节点和分片算法配置信息。主要是解决配置简化、配置一体化。

• 语法格式

行表达式的使用非常直观，只需要在配置中使用${ expression }或$->{ expression }标识行表达式即可。例如：

${begin..end} 表示范围区间 
${[unit1, unit2, unit_x]} 表示枚举值 

行表达式中如果出现多个${}或$->{}表达式，整个表达式结果会将每个子表达式结果进行笛卡尔(积)组合。例如，以下行表达式：

${['online', 'offline']}_table${1..3} 
$->{['online', 'offline']}_table$->{1..3} 

最终会解析为：

online_table1, online_table2, online_table3, 
offline_table1, offline_table2, offline_table3 

• 数据节点配置

对于均匀分布的数据节点，如果数据结构如下：

db0
├── b_order2 
└── b_order1 
db1
├── b_order2 
└── b_order1 

用行表达式可以简化为：

db${0..1}.b_order${1..2} 

或者

db$->{0..1}.b_order$->{1..2} 

对于自定义的数据节点，如果数据结构如下：

db0
├── b_order0 
└── b_order1 
db1
├── b_order2 
├── b_order3 
└── b_order4 

用行表达式可以简化为：

db0.b_order${0..1},db1.b_order${2..4}

• 分片算法配置

行表达式内部的表达式本质上是一段Groovy代码，可以根据分片键进行计算的方式，返回相应的

真实数据源或真实表名称。

ds${id % 10} 
或者
ds$->{id % 10} 

结果为：ds0、ds1、ds2... ds9

• 分布式主键

ShardingSphere不仅提供了内置的分布式主键生成器，例如UUID、SNOWFLAKE，还抽离出分布式主键生成器的接口，方便用户自行实现自定义的自增主键生成器。

• 内置主键生成器

• 自定义主键生成器

spring.shardingsphere.sharding.tables.t_book.key-generator.column=id

spring.shardingsphere.sharding.tables.t_book.key-generator.type=LAGOUKEY

读写分离

读写分离是通过主从的配置方式，将查询请求均匀的分散到多个数据副本，进一步的提升系统的处理能力。

• 主从架构：读写分离，目的是高可用、读写扩展。主从库内容相同，根据SQL语义进行路由。
• 分库分表架构：数据分片，目的读写扩展、存储扩容。库和表内容不同，根据分片配置进行路由。

将水平分片和读写分离联合使用，能够更加有效的提升系统性能，

下图展现了将分库分表与读写分离一同使用时，应用程序与数据库集群之间的复杂拓扑关系。

读写分离虽然可以提升系统的吞吐量和可用性，但同时也带来了数据不一致的问题，包括多个主库之间 的数据一致性，以及主库与从库之间的数据一致性的问题。 并且，读写分离也带来了与数据分片同样的 问题，它同样会使得应用开发和运维人员对数据库的操作和运维变得更加复杂。

读写分离应用方案

在数据量不是很多的情况下，我们可以将数据库进行读写分离，以应对高并发的需求，通过水平扩展从 库，来缓解查询的压力。如下：

分表+读写分离

在数据量达到500万的时候，这时数据量预估千万级别，我们可以将数据进行分表存储。

分库分表+读写分离

在数据量继续扩大，这时可以考虑分库分表，将数据存储在不同数据库的不同表中，如下：

透明化读写分离所带来的影响，让使用方尽量像使用一个数据库一样使用主从数据库集群，是ShardingSphere读写分离模块的主要设计目标。

主库、从库、主从同步、负载均衡

核心功能

• 提供一主多从的读写分离配置。仅支持单主库，可以支持独立使用，也可以配合分库分表使用独立使用读写分离，支持SQL透传。不需要SQL改写流程
• 同一线程且同一数据库连接内，能保证数据一致性。如果有写入操作，后续的读操作均从主库读取。
• 基于Hint的强制主库路由。可以强制路由走主库查询实时数据，避免主从同步数据延迟。

不支持项

• 主库和从库的数据同步
• 主库和从库的数据同步延迟
• 主库双写或多写
• 跨主库和从库之间的事务的数据不一致。建议在主从架构中，事务中的读写均用主库操作。

主从复制原理

MySQL里有一个概念，叫binlog日志，就是每个增删改类的操作，会改变数据的操作，除了更新数据以外，对这个增删改操作还会写入一个日志文件，记录这个操作的日志。

主库将变更写binlog日志，然后从库连接到主库之后，从库有一个IO线程，将主库的binlog日志拷贝到自己本地，写入一个中继日志中。接着从库中有一个SQL线程会从中继日志读取binlog，然后执行binlog日志中的内容，也就是在自己本地再次执行一遍SQL，这样就可以保证自己跟主库的数据是一样的。

这里有一个非常重要的一点，就是从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行SQL的特点，在高并发场景下，从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。

而且这里还有另外一个问题，就是如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就丢失了。

所以mysql实际上在这一块有两个机制，一个是半同步复制，用来解决主库数据丢失问题；一个是并行复制，用来解决主从同步延时问题。

这个所谓半同步复制，semi-sync复制，指的就是主库写入binlog日志之后，就会将强制此时立即将数据同步到从库，从库将日志写入自己本地的relay log之后，接着会返回一个ack给主库，主库接收到至少一个从库的ack之后才会认为写操作完成了。

所谓并行复制，指的是从库开启多个线程，并行读取relay log中不同库的日志，然后并行重放不同库的日志，这是库级别的并行。

官方文档地址：https://shardingsphere.apache.org/document/legacy/3.x/document/cn/overview/