【分库分表】sharding-jdbc—解决的问题

一、遇到的问题

随着互联网技术和业务规模的发展，单个db的表里数据越来越多，sql的优化已经作用不明显或解决不了问题了，这时系统的瓶颈就是单个db了（或单table数据太大）。这时候就涉及到分库分表的问题了，很多开源解决方案来解决这个问题。比如（排名不分先后）：

• 当当网的sharding-jdbc
• 携程的ctripcorp
• 阿里的Cobar
• 第三方mycat（基于Cobar）

本片主要以sharding-jdbc为例研究下分库分表的实施方案。

二、sharding-jdbc简介

1. Sharding-JDBC是一个开源的适用于微服务的分布式数据访问基础类库。
2. Sharding-JDBC定位为轻量级java框架，使用客户端直连数据库，以jar包形式提供服务，未使用中间层，无需额外部署，无其他依赖，DBA也无需改变原有的运维方式，可理解为增强版的JDBC驱动，旧代码迁移成本几乎为零。
3. Sharding-JDBC完整的实现了分库分表，读写分离和分布式主键功能，并初步实现了柔性事务。
4. 性能比较，摘录自官方：

三、解决的问题

1. 分库分表

• SQL解析功能完善，支持聚合，分组，排序，LIMIT，TOP等查询，并且支持级联表以及笛卡尔积的表查询
• 支持内、外连接查询
• 分片策略灵活，可支持=，BETWEEN，IN等多维度分片，也可支持多分片键共用，以及自定义分片策略
• 基于Hint的强制分库分表路由

2. 读写分离

• 独立使用读写分离支持SQL透传
• 一主多从的读写分离配置，可配合分库分表使用
• 基于Hint的强制主库路由

3. 柔性事务

• 最大努力送达型事务
• TCC型事务(TBD)

4. 分布式主键

• 统一的分布式基于时间序列的ID生成器

5. 兼容性

• 可适用于任何基于java的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC
• 可基于任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid等
• 理论上可支持任意实现JDBC规范的数据库。目前支持MySQL，Oracle，SQLServer和PostgreSQL

6. 灵活多样的配置

• Java
• YAML
• Inline表达式
• Spring命名空间
• Spring boot starter

7. 分布式治理能力 (2.0新功能)

• 配置集中化与动态化，可支持数据源、表与分片策略的动态切换(2.0.0.M1)
• 客户端的数据库治理，数据源失效自动切换(2.0.0.M2)
• 基于Open Tracing协议的APM信息输出(2.0.0.M3)