业务背景

F6 汽车科技，是一家专注于汽车后市场信息化建设的互联网平台公司，为维修企业开发智慧管理平台。各个维修企业（后文简称商户）之间的数据是相互隔离的，不同商户之间的数据理论上可以存储在不同库不同表。随着公司业务发展迅速，有些表的数据量增长迅速，单表总的数据量达到千万甚至亿的级别，系统越来越难以满足业务的高速发展。另外随着业务发展公司也在对系统进行拆分，按照不同域不同业务拆分成许多微服务，随之也就垂直拆分成了不同的业务库。

业务挑战

关系型数据库由于单机存储容量、连接数、处理能力都有限，容易成为系统瓶颈。从性能上看，当单表的数据量达到千万以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。另外单库的连接数有限，如果数据库查询的 QPS 过高，那么就需要通过分库来分担单个数据库的连接压力。从可用性上看，单个数据库如果发生意外，很可能会丢失所有数据，影响所有业务，分库可以隔离故障，减少业务的影响范围。

总体方案

结合公司实际情况我们选择了 ShardingSphere 实现 Sharding。按照公司现有业务逻辑，因此采用商户 ID 作为分片键（ShardingKey），保证一个商户的工单数据，分配在同一个库同一个单表中，避免了多表查询关联的性能损耗，后期分片到多个库时，可以避免跨库事务及跨库 JOIN。 商户 ID 数据库中的类型为 BIGINT(20)，为了保证后续分库扩容的需求，采用基因法，选取商户 ID 最后两位作为分库基因，按照双倍扩容的规则，可以最大扩展到 64 个库中。剩余位数的值用于分表，分片到 32 个分表中。

规则如下（10545055917999668983 为某商户 ID）：

105450559179996689    83
分表基因值 % 32    分库基因值 % 1

最后两位 83 用于分库，暂时数据只分片到 f6xxx 一个库中，因此余数为 0，后期数据量增加，扩展至多个库。剩余数值 105450559179996689 用于分表，首次分为 32 个单表，取模余数对应具体的分表下标，为 0~31。

按照公司系统现状及开发功能能快速迭代分步上线的背景，因此我们制定了先分表再拆库的方案，考虑到分库分表改动影响比较大，因此需要灰度上线，一旦有问题需要快速回滚，不能影响正常业务。具体实施步骤如下：

分表

（1）工程从 JDBC 切到 Sharding-JDBC 数据源连接方式 （2）写库业务解耦和代码迁移 （3）历史数据和增量数据同步 （4）切分表

分库

（1）读库业务迁移 （2）数据迁移 （3）切读库 （4）切写库

选择 Apache ShardingSphere 的理由

• 社区活跃，目前已经升级至 5.0 版本，仍处于快速迭代中；
• 成功应用案例多，京东、当当等大公司广泛应用；
• 使用简单，Sharding-JDBC 快速集成项目，不需要部署额外服务；
• 兼容性好，路由至单数据节点，SQL 100% 支持；
• 性能优异，损耗低，官网有测试结果；