Sharding JDBC 分库分表实战

简介

Sharding-JDBC是一个开源的分布式数据库中间件解决方案。它在Java的JDBC层以对业务应用零侵入的方式额外提供数据分片，读写分离，柔性事务和分布式治理能力。并在其基础上提供封装了MySQL协议的服务端版本，用于完成对异构语言的支持。

基于JDBC的客户端版本定位为轻量级Java框架，使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。

封装了MySQL协议的服务端版本定位为透明化的MySQL代理端，可以使用任何兼容MySQL协议的访问客户端(如：MySQL Command Client, MySQL Workbench等)操作数据，对DBA更加友好。

准备

进行分库分表前,需要根据业务对分库分表的策略进行评估，总结了下大致可以分为以下方面

1.选择分表还是分库

第一，如果分库分表主要解决的是数据量太大查询慢的问题。那么我们只要减少每次查询的数据总量就可以了，也就是说，分表就可以解决问题。
第二，如果分库分表主要是为了应对高并发的问题。一个数据库实例撑不住，需要将请求分发到不同数据库实例上面去，就需要对数据库进行分库的操作。简单地说，数据量大，就分表；并发高，就分库。并且分表和分库的数量需要根据评估的数据量和未来的并发量来评估。

2.分片键(Sharding Key)的选择

选择分库分表的时候，我们需要选择一个合适的列或者属性，作为分库分表的依据。原则上根据业务的不同,尽量选择一个列，做到兼容让大部分的业务查询落到一个分片上，尽量避免sql解析的时候落到过多的分片上，不然在做分页或者各种join操作的时候，分库分表往往会显得得不偿失，甚至性能可能更差。

3.分片策略
常用三种分片算法，1. 范围分片 容易产生热点问题，但对查询更友好，适合适合并发量不大的场景；2. 哈希分片 比较容易把数据和查询均匀地 3.查表法更灵活，但性能稍差。

4.分布式唯一主键的选择
具体的实现可以参考https://tech.meituan.com/2017/04/21/mt-leaf.html的介绍,对各个分片算法实现作了比较详细的对比和介绍。

实践

好啦，明确上面的准备工作,确定了分多少表，分多少库，以及对应表的分片键以及分片策略和分布式唯一主键的选择等，我们就可以进行相关的配置了。

引入maven依赖,当前稳定版本为4.0.0。

规则配置，我们这里以java config的方式进行配置，根据商品表，以商品表所属的店铺store_id为分为Sharding Key),分为512个表,分两个库进行配置

上图PreciseModuloShardingTableAlgorithm分表规则配置， 使用哈希分片
[]

最后引入shardingDataSource，就可以直接使用datasoruce操作数据库,是不是很简单 😏

总结

Sharding JDBC不仅仅支持java配置，还支持# YAML , SPRING BOOT START,# SPRING 命名空间(xml方式)等方式进行配置。

缺点：当然数据库的分库分表还有很多问题，包括历史数据的迁移，扩容问题，做分表分库后无法对原始sql做百分百的sql解析，需要放弃掉一些Sharding JDBC不支持的sql（INSERT … SELECT,HAVING,UNION,VALUES语句不支持运算表达式等,具体可查看https://shardingsphere.apache.org/document/current/cn/features/sharding/use-norms/sql/#%E4%B8%8D%E6%94%AF%E6%8C%81%E9%A1%B9）,性能的损耗(损耗相对较小)等，

优点：Sharding JDBC也有很多优点，简单配置，和透明的使用方式也给我们在开发过程中带来了很大的便利。不仅支持数据分片，也对数据库读写分离，分布式事物(内置seata)，数据库的服务治理，数据的加密作了不同程度的支持。有兴趣的小伙伴可以去官网https://shardingsphere.apache.org/查看其实现和具体使用