热点技术讲解：ShardingJdbc分库分表实战案例解析（上）

在对诸如订单、交易、支付等实时在线业务系统的研发、维护过程中，随着业务量的快速增长，我们经常会遇到由于关系型数据库（如:MySql）单表数据量增长过大而引发的线上事故；虽然这些事故多数时候是由于不合理的慢SQL而引起的系统雪崩，但有时也会出现由于数据库热点块IO争用而引发的系统性性能下降。总之，单表数据量的无限增长总是会在这样或那样的情况下增加系统的不稳定性因素。

所以在大规模实时系统的设计中，除了重点考虑应用结构的分布式化外，往往也不应该忽略数据库实时存储、计算能力扩展性方面的考虑。目前解决实时数据增长一般有两种思路：一种是直接采用分布式数据库（例如:***Tidb、OceanBase***之类）；另一种是对关系型数据库进行分库分表来最大化利用现有数据库的实时计算能力。绝大部分情况下，后一种方案往往会更现实一些。

本文的主要内容就是通过模拟一个交易系统的订单库，来具体演示如何通过***ShardingJdbc***实现交易订单数据的分库分表存储。在这个过程中会到涉及分库分表实践的三种主要场景：1、新系统在设计之初直接使用分库分表方案；2、历史系统运行一段时间后如何平滑地实施分库分表；3、对现有分库分表逻辑的Scaling操作(包括减少分表、增加分表)涉及的数据迁移问题。

Spring Boot集成ShardingJdbc实现分库分表

交易系统的订单数据是分库分表的一个非常典型场景，由于交易系统对单条数据的实时处理性能要求很高，所以一旦单个订单表数据量规模达到10亿+，就很容易出现由于数据库热点块IO争用而导致的性能下降，也很容易出现个别不谨慎的SQL操作而引起的系统性雪崩。

但一旦决定实施分库分表就要提前做好存储规划，并对未来数据增长的规模进行一定的评估，同时做好未来增加分库、增加分表的系统Scaling方案。此外，分库分表的实施还要考虑应用的接入难度，分库分表的细节逻辑应该对应用透明；所以一般来说我们需要一个中间代理层来屏蔽分库分表对应用程序本身带来的侵入。

目前在Java社区中比较知名的分库分表代理组件就是ShardingJdbc（目前已被集成在Apache开源项目 ShardingSphere之中），ShardingJdbc本质上是一个轻量级的JDBC驱动代理，在使用的过程中只需要依赖相关Jar包即可，并不需要额外部署任何服务。通过系统配置文件就可以实现分库分表逻辑的定义，并实现应用透明代理访问。

接下来，我们以Spring Boot为例演示如何集成ShardingJdbc实现对交易订单的分库分表操作，具体步骤如下：

1）、订单数据的分库分表规划

在系统设计之初，如果能够预见到未来数据量的增长规模，那么提前做好分库分表规划是非常有远见的。从分库分表的形式上来说，一般可以有两类规划方式：1）、