海量数据解决方案ShardingSphere分库分表详解

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

1.2. ShardingSphere-Proxy

Sharding-Proxy 定位为透明化的数据库代理端 ，提供封装了数据库二进制协议的服务端版本，用

于完成对异构语言的支持。

目前提供MySQL 和 PostgreSQL版本，它可以使用任何兼容MySQL/PostgreSQL协议的访问客户

端(如：MySQL Command Client, MySQL Workbench,Navicat 等)操作数据，对DBA更加友好。

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

1.3. ShardingSphere-Sidecar

Sharding-Sidecar 定位为 Kubernetes 的云原生数据库代理，以 Sidecar 的形式代理所有对数据库

的访问。通过无中心、零侵入 的方案提供与数据库交互的的啮合层，即 Database Mesh，又可称

数据库网格。

Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关

注的是交互，是将杂乱无章的应用与数据库之间的交互有效的梳理。使用 Database Mesh，访问

数据库的应用和数据库终将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即

可，它们都是被啮合层所治理的对象。

1.4. 混合架构

ShardingSphere-JDBC 采用无中心化架构 ，适用于 Java开发的高性能的轻量级 OLTP 应用；

ShardingSphere-Proxy 提供静态入口以及异构语言的支持 ，适用于 OLAP 应用以及对分片数据库

进行管理和运维的场景。

Apache ShardingSphere 是多接入端共同组成的生态圈。通过混合使用 ShardingSphere-JDBC

和ShardingSphere-Proxy，并采用同一注册中心统一配置分片策略，能够灵活的搭建适用于各种场

景的应用系统，使得架构师更加自由的调整适合与当前业务的最佳系统架构。

2、数据分片

从性能方面 来说，由于关系型数据库 大多采用B+树类型的索引，在数据量超过阈值的情况下，索

引深度的增加也将使得磁盘访问的IO次数增加，进而导致查询性能的下降 ；同时，高并发访问请求

也使得集中式数据库成为系统的最大瓶颈。

从运维成本方面 考虑，当一个数据库实例中的数据达到阈值以上，对于DBA的运维压力就会增

大。数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。一般来讲，单一数据库实例

的数据的阈值在1TB之内，是比较合理的范围。

2.1 垂直分片

按照业务拆分的方式 称为垂直分片 ，又称为纵向拆分，它的核心理念是专库专用。

在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则是按照业

务将表进行归类，分布到不同的数据库中，从而将压力分散至不同的数据库。

下图展示了根据业务需要，将用户表和订单表垂直分片到不同的数据库的方案。

垂直分片往往需要对架构和设计进行调整。

通常来讲，是来不及应对互联网业务需求快速变化的；而且，它也并无法真正的解决单点瓶颈。垂

直拆分可以缓解数据量和访问量带来的问题，但无法根治。

如果垂直拆分之后，表中的数据量依然超过单节点所能承载的阈值 ，则需要水平分片来进一步处

理。

2.2 水平分片

水平分片又称为横向拆分 。相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字

段（或某几个字段） ，根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。

例如：根据主键分片，偶数主键的记录放入0库（或表），奇数主键的记录放入1库（或表），如下

图所示。

水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由 ，是分库分表的标准解决方

案。

2.3 目标

尽量透明化分库分表所带来的影响，让使用方尽量像使用一个数据库一样使用水平分片之后的数据

库集群，是 Apache ShardingSphere 数据分片模块的主要设计目标。

2.4 核心概念

数据节点

数据分片的最小单元 。由数据源名称和数据表组成，例如：ds_0.t_order_0。

分片键

用于分片的数据库字段，是将数据库(表)水平拆分的关键字段。例：将订单表中的订单主键的尾数

取模分片，则订单主键为分片字段。

SQL 中如果无分片字段，将执行全路由，性能较差。

除了对单分片字段的支持，Apache ShardingSphere 也支持根据多个字段进行分片。

分片算法

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

分片算法需要应用方开发者自行实现，可实现的灵活度非常高。

分片策略

包含分片键和分片算法 ，由于分片算法的独立性，将其独立抽离。真正可用于分片操作的是分片键

+分片算法，也就是分片策略。目前提供 5 种分片策略。

行表达式

使用表达式可以简化配置 ，只需要在配置中使用${ expression } 或 $->{ expression } 标识行表

达式即可

${begin..end}表示范围区间

${[unit1, unit2, unit_x]} 表示枚举值

行表达式中如果出现连续多个 ${ expression} 或 $->{ expression } 表达式，整个表达式最终的

结果将会根据每个子表达式的结果进行笛卡尔组合。

例如，{1..3} 最终会被解析为 online_table1, online_table2, online_table3, offline_table1,

offline_table2, offline_table3

分布式主键

在分片规则配置模块可配置每个表的主键生成策略 ，默认使用雪花算法（snowflake）生成 64bit 的

长整型数据

雪花算法 是由 Twitter 公布的分布式主键生成算法 ，它能够保证不同进程主键的不重复性，以及相

同进程主键的有序性。

实现原理

在同一个进程中，它首先是通过时间位保证不重复，如果时间相同则是通过序列位保证。同时由于

时间位是单调递增的，且各个服务器如果大体做了时间同步，那么生成的主键在分布式环境可以认

为是总体有序的，这就保证了对索引字段的插入的高效性。例如 MySQL 的 Innodb 存储引擎的主

键。

使用雪花算法生成的主键，二进制表示形式包含 4 部分，从高位到低位分表为：1bit 符号位、

41bit时间戳位、10bit 工作进程位以及 12bit 序列号位。

符号位(1bit)

预留的符号位，恒为零。

时间戳位(41bit)

41 位的时间戳可以容纳的毫秒数是 2 的 41 次幂，一年所使用的毫秒数是：365 * 24 * 60 * 60 *

1000。

通过计算可知：结果约等于 69.73 年。Apache ShardingSphere的雪花算法的时间纪元从2016年

11月1日零点开始，可以使用到2086年，相信能满足绝大部分系统的要求。

工作进程位(10bit)

该标志在 Java 进程内是唯一的，如果是分布式应用部署应保证每个工作进程的 id 是不同的。该值

默认为 0，可通过属性设置。

序列号位(12bit)

该序列是用来在同一个毫秒内生成不同的 ID。如果在这个毫秒内生成的数量超过 4096 (2的12次

幂)，那么生成器会等待到下个毫秒继续生成。

雪花算法主键的详细结构见下图：

2.5 使用规范

下面列出已明确可支持的SQL种类以及已明确不支持的SQL种类，尽量让使用者避免踩坑。

支持项

路由至单数据节点

100%全兼容（目前仅MySQL，其他数据库完善中）

路由至多数据节点

全面支持DML、DDL、DCL、TCL和部分DAL 。支持分页、去重、排序、分组、聚合、关联查询 （不支持跨库关联）。

不支持项

路由至多数据节点

不支持CASE WHEN、HAVING、UNION (ALL) ，有限支持子查询。

https://shardingsphere.apache.org/document/current/cn/features/sharding/use-norms/sql/

3、读写分离

读写分离虽然可以提升系统的吞吐量和可用性，但同时也带来了数据不一致的问题 。这包括多个

主库之间的数据一致性， 以及主库与从库之间的数据一致性的问题。

并且，读写分离也带来了与数据分片同样的问题，它同样会使得应用开发和运维人员对数据库的操

作和运维变得更加复杂。

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