初次接触Sharding-JDBC并实际应用

Sharding-Jdbc是什么

在学习新的技术之前，先要了解这个技术是什么，能够解决什么样的问题。Sharding-Jdbc是ShardingSphere的一个组成部分，而ShardingSphere是从Apache毕业的一款分布式的数据库生态系统， 可以将任意数据库转换为分布式数据库，并通过数据分片、弹性伸缩等能力对原有数据库进行增强。Sharding-Jdbc被官方定义为一个轻量级的Java框架，在原Jdbc做了额外的封装并提供服务，在使用时，只需要引入对应的jar包即可。目前支持MySQL，PostgreSQL，Oracle等多种数据库，支持Mybatis,JPA等多种ORM框架，支持c3p0,DBCP,Druid等多种数据库连接池。目前Sharding-Jdbc的功能有很多，包括数据分片，分布式事务，读写分离等，其中使用最多的就是数据分片。

官网地址： shardingsphere.apache.org/document/cu…

数据分片

从性能上讲，在MySQL单一节点部署的情况下，当数据量达到一定的级别时，性能会大大下降。我们都知道MySQL的索引采用B+Tree的数据结构进行实现的，当存储大数据量时，B+Tree的深度就会增加，树的深度增加，那就意味着磁盘IO的次数也在增加。从运维成本上讲，单机数据库的数据备份或迁移会随着数据量的增加而增加。而数据分片，就是通过某种规则，将数据分发到不同的数据库或数据表中，从而提高数据库性能的一种解决方式。通过分库和分表进行数据的拆分来使得各个表的数据量保持在阈值以下，以及对流量进行疏导应对高访问量，是应对高并发和海量数据系统的有效手段。数据分片按照拆分方式可以分为垂直分片和水平分片

垂直分片

垂直分片可以分为垂直分库和垂直分表，可以理解为专库专用，专表专用。这种垂直分表方式应该在项目开始前或者建表前就应该考虑，否则后期改动很大。以我司的部分业务为例，用户在接种疫苗前，可以在手机上进行预约，这时预约信息会存储在预约表中(app_user_appointment)，当接种完成后会生成一条接种记录并存储在记录表中(app_user_vaccinate_record)。

• 垂直分库：按照功能划分，将数据存储在不同的数据库。传统模式下，所有的数据表都在一个数据库下，后期数据将会愈发臃肿。而垂直分库，对数据进行了划分处理，比如预约表的数据存储在数据库DB0中，而接种记录数据存储在数据库DB1中，这样就可以做到专库专用，库与库之间不存在什么影响，数据也会被各个库分担。

• 垂直分表：将一个大表拆分为多个子表，减少字段的水平膨胀。比如可以将预约表app_user_appointment拆分为预约信息主表app_user_appointment_info和预约信息详情表app_user_appointment_detail。

水平分片

水平分片可以分为水平分库和水平分表。水平分片在于多个库或多张表结构相同并且命名存在一定的规律，这样在存储数据时，可以根据一个或多个字段并结合一定的规则，将数据存储到不同的数据库或数据表中。通过自己的实践发现，水平分片在扩容方面，要比垂直分片来的容易。

分片应用

在后面的例子中将会采用水平分片的方式，具体使用的相关技术有SpringBoot+MybatisPlus+Mysql5.7+ShardingJdbc+Druid。那么现在来模拟这样一个需求，用户在注册时会选择所在的省市，注册完成后会进行疫苗预约操作。后台在存储数据时，根据用户选择的省份编码来进行水平分库，用户预约疫苗时根据所在的市区编码进行水平分表。假设现在有两个省，分别为江苏省(310000),浙江省(320000)。其中江苏省下有两个市开通了预约功能，分别为南京市(310010)和苏州市(310020)。浙江省下有两个开通了预约功能，分别为杭州(320010)和宁波(320020)

根据上面的案例可以确定出需要针对于江苏省的数据库shardingjdbc_1和浙江省的数据库shardingjdbc_2，以及对应的数据表。

-- 模拟用户表(江苏) --
CREATE TABLE `app_user`  (
  `user_id` bigint(20) NOT NULL,
  `prov_code` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `city_code` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `user_name` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  PRIMARY KEY (`user_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;
1
2
3
4
5
6
7
8

-- 模拟用户预约表(江苏-南京) --
CREATE TABLE `app_user_appointment_31001`  (
  `id` int(11) NOT NULL,
  `prov_code` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `city_code` varchar(255) CHA
1
2
3
4