一、前言

1、概述

之前调研形成一篇文章《MySQL 分表方案及中间件介绍》，主要说明了分库分表的技术及主流的中间件，本文主要讨论下分库分表的技术选型及在项目中的具体应用。

2、回顾

2.1分库

随着业务的发展，数据库成为瓶颈，这时候我们需要将每个服务相关的表拆出来单独建立一个数据库，这其实就是“分库”。目前流行的微服务架构也是分库概念在数据库方面的一种实现，比如用户应用对应用户表，订单应用对应订单表。

2.2分表

分表分为水平切分和垂直切分，垂直切分主要是对表进行切分，把常用的和不常用字段的分开，比如用户表中的姓名、工号、年龄放在基本表，学历、工作经历放在另一张表。水平切分是指对表的数据量进行切分，比如按时间，hash等进行区分。

总结如下：

垂直切分：基于表或字段划分，表结构不同。

水平切分：基于数据划分，表结构相同，数据不同。

3、技术复杂度

由于分库分表技术的实施，原来的单库单表操作的纯粹性就不存在了，需要考虑这种技术带来的技术复杂性。所以在应用分库分表时，不可盲目使用，需充分考虑到系统的瓶颈。那技术复杂度有哪些呢？

3.1多数据库

多个数据库中数据操作，比如分库后，多个数据库关联查询、汇总等；多个数据库的管理问题等。

3.2跨表查询

同一库也要考虑分表查询join。

3.3分布式ID

单表的id 自增主键不能用了，会出现id 重复。

3.4分布式事务

单表事务不可用了，需考虑分布式事务进行处理了。

即然增加了分库分表，变复杂了，有什么中间件可以使用吗？各大厂商都存在着相应的解决方案，我们从项目应用的角度去选择。

二、技术选型

1、中间件的两大方案

Client模式：在连接池上增加一层封装。和系统的紧密性较高。

Proxy模式：独立成服务，接收Sql作处理。

两种模式的代表产品及优缺点如下所示：

2、中间件对比

这里我们只考虑用户量高的产品并作对比。

2.1 sharding-sphere

作为Apache的顶级项目，其官网定义为：将任何数据库转换为分布式数据库系统的生态系统，并通过分片、弹性伸缩、加密等功能对其进行增强。

其官网讲的很详细，了解使用、原理等可参考官网。官网是学习的最佳方式。

其发展历程为：

其关键特性为：

它包含两大产品：

ShardingSphere-Proxy：被定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。

ShardingSphere Proxy提供了一个封装数据库二进制协议以支持异构语言的数据库服务器。目前提供MySQL和PostgreSQL协议。它可以使用任何一种与MySQL或PostgreSQL协议兼容的终端来操作数据，这对DBA更友好。其特性为：

• 对应用程序透明，可以直接作为MySQL/PostgreSQL使用；

• 兼容基于MySQL的数据库，如MariaDB，以及基于PostgreSQL的数据库，例如openGauss；

• 适用于任何兼容MySQL/PostgreSQL协议的客户端，如MySQL命令客户端、MySQL工作台等。

ShardingSphere-JDBC：一个轻量级Java框架，在Java的JDBC层提供额外的服务。

ShardingSphereJDBC通过客户端直接连接到数据库，它以jar的形式提供服务，不需要额外的部署和依赖。它可以被认为是JDBC驱动程序的增强版，与JDBC和各种ORM框架完全兼容。其特性为：

• 适用于任何基于JDBC的ORM框架，如JPA、Hibernate、Mybatis、Spring JDBC Template，或直接使用JDBC；

• 支持任何第三方数据库连接池，如DBCP、C3P0、BoneCP、HikariCP；

• 支持任何类型的JDBC标准数据库：MySQL、PostgreSQL、Oracle、SQLServer和任何适用于JDBC的数据库。

sharding-jdbc本质上实现 JDBC 的核心接口。

两者对比为：

2.2 mycat

mycat是Java语言开发的目前比较主流的数据库中间件之一，是mycat团队在阿里开源的 Cobar 产品基础上而研发的，也一直在维护。mycat实现了 MySQL 协议的服务器，前端用户可以把它看作是一个数据库代理，用 MySQL 客户端工具和命令行访问，而其后端可以用 MySQL 原生协议与多个 MySQL 服务器通信，也可以用 JDBC 协议与大多数主流数据库服务器通信。

两者对比如下：

其中Sharding-jdbc的分布式事务已经有一定粒度的实现。

3、选型

由于我们技术平台中数据量大主要集中在物联网数据这块，所以我们只需考虑物联网的实时数据和历史数据，以及分库分表所带来的技术问题，中间件是否能够解决。

因为实现简单及考虑到我们团队的结构，我们考虑的是ShardingSphere-JDBC。分库分表带来技术问题sharding-jdbc基本都能够解决。

数据库表我们按日期进行划分，例如：

一般分库分表原则：

根据容量（当前容量和增长量）评估分库或分表个数 -> 选key（均匀）-> 分表规则（hash或range等）-> 执行（一般双写）-> 扩容问题（尽量减少数据的移动）。

sharding-jdbc 的原理：

三、项目实践

1、引用pom

<dependency>
 <groupId>org.apache.shardingsphere</groupId>
 <artifactId>sharding-jdbc-core</artifactId>
 <version>4.1.1</version>
</dependency>

目前最新版本的5.3.2。

2、配置文件添加数据源

在application-druid.yml添加分库分表数据源，位置和主数据源同级位置。

# 数据源配置

spring:
datasource:
type: com.alibaba.druid.pool.DruidDataSource
driverClassName: com.mysql.cj.jdbc.Driver
druid:
# 主库数据源
master:
url: jdbc:mysql://localhost:3306/ry473?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=GMT%2B8
username: root
password: password
# 订单库1
shardsource:
enabled: true
url: jdbc:mysql://localhost:3306/ry473?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=GMT%2B8
username: root
password: password

3、druid配置数据源

@Bean(name = "dynamicDataSource")
@Primary
public DynamicDataSource dataSource(DataSource masterDataSource)
{
Map<Object, Object> targetDataSources = new HashMap<>();
targetDataSources.put(DataSourceType.MASTER.name(), masterDataSource);
setDataSource(targetDataSources, DataSourceType.SLAVE.name(), "slaveDataSource");
setDataSource(targetDataSources, DataSourceType.SHARDING.name(), "shardingDataSource");
return new DynamicDataSource(masterDataSource, targetDataSources);
}

4、添加shardingsphere配置类

设置分库、分表配置，主键规则，指定需使用的策略等。

5、添加分表策略

6、服务应用

通过注解@DataSource(DataSourceType.SHARDING)，框架判断对应的操作需要使用分表的数据库连接。

四、尾声

类似 TiDB、OceanBase 这样纯粹的分布式数据库完全可以兼容分库分表，也就是说，原来分库分表相关的技术，你现在换个兼容的存储就行了。

但是用分布式数据库也许会更复杂，对于目前我们业务来说的话，分库分表还是适用的，也许未来的天下都是分布式数据库天下，但至少此刻，分库分表能解决我的问题。