一、Sharding-JDBC 采用在 JDBC 层扩展分库分表，支持读写分离，是一个以 jar 形式提供服务的轻量级组件，其核心思路是小而美地完成最核心的事情，基于 JDBC 层进行分片的好处是轻量、简单、兼容性好以及无需额外的运维工作。缺点是无法跨语言，目前仅支持 Java

二、Sharding-JDBC 适用于哪些场景，不适用于哪些场景？是否有性能评估？

（1）适合场景：

对于关系型数据库数据量很大的情况，需要进行水平拆库和拆表（即分库和分表），这种场景很适合使用 Sharding-JDBC。

举例说明：假设有一亿数据的用户库，放在 MySQL 数据库里查询性能会比较低，而采用水平拆库，将其分为 10 个库，根据用户的 ID 模10，这样数据就能比较平均的分在 10 个库中，每个库只有 1000w 记录，查询性能会大大提升。分片策略类型非常多，大致分为 Hash +Mod、Range、Tag 等。

Sharding-JDBC 还提供了读写分离的能力，用于减轻写库的压力。

此外，Sharding-JDBC 可以用在 JPA 场景中，如 JPA、Hibernate、Mybatis，Spring JDBC Template 等任何 Java 的 ORM 框架。Java 的 ORM 框架也都是采用 JDBC 与数据库交互。这也是我们选择在 JDBC 层，而非选择一个 ORM 框架进行开发的原因。我们希望 Sharding-JDBC 可以尽量的兼容所有的 Java 数据库访问层，并且无缝的接入业务应用。

（2）不合适的场景主要是两方面：

（2.1）不适合 OLAP 的场景。虽然 Sharding-JDBC 也能做聚合分组查询，但大量的 OLAP 场景，仍然会比较慢，而且复杂的SQL（如子查询等）目前还没有支持。这种查询不太适合大数据和高并发的互联网 online 数据库，建议使用合理的 OLTP 查询。

（2.2）不适合事务强一致的要求。目前 Sharding-JDBC 的事务支持两种，一种是弱 XA，另一种是柔性事务（BASE）。因为 XA的两阶段或三阶段提交其性能较低，因此互联网公司基本不会采用。而无论是弱 XA还是柔性事务，都无法保证事务在任意时间段完全保证一致，其中柔性事务能保证数据的最终一致性，但达到最终一致性的时间仍然不可控。因此对于对跨库事务强一致要求很高的场景，需要从设计方面去考虑数据库schema 的合理性。

对于 JTA 事务，目前 Shariding-JDBC 没有实现 JTA 的标准。而且由于在互联网场景下使用 JTA 比较少见，因此暂时不支持 JTA 事务。

（3）性能测试报告如下：

（3.1）使用Sharding-JDBC，性能是大家最关心的问题。在数据量一致的情况下，使用Sharding-JDBC和原生JDBC的性能测试报告如下：

查询操作：Sharding-JDBC的TPS为JDBC的TPS的99.8%。

插入操作：Sharding-JDBC的TPS为JDBC的TPS的90.2%。

更新操作：Sharding-JDBC的TPS为JDBC的TPS的93.1%。

可以看到，Sharding-JDBC在查询中的性能损失非常低，插入和更新略高。

（3.2）将单表的数据拆分为二，放入两个表中，使用Sharding-JDBC和原生JDBC的性能测试报告如下：

查询操作：TPS双库比单库可以增加大约94%的性能。

插入操作：TPS双库比单库可以增加大约60%的性能。

更新操作：TPS双库比单库可以增加大约89%的性能。

结果表明，Sharding-JDBC可有效利用水平扩展大幅度提升性能。

三、sharding-jdbc架构图

四、sharding-jdbc与mycat 相似性以及区别

从设计理念上看确实有一定的相似性。主要流程都是SQL 解析 -> SQL 路由 -> SQL 改写 -> SQL 执行 -> 结果归并。但架构设计上是不同的。Mycat 是基于 Proxy，它复写了 MySQL 协议，将 Mycat Server 伪装成一个 MySQL 数据库，而 Sharding-JDBC 是基于 JDBC 的扩展，是以 jar 包的形式提供轻量级服务的。

五、sharding-jdbc支持读写分离

Sharding-JDBC 从 1.3.0 开始支持读写分离。其功能包括：

（5.1）根据配置区分写库和多个读库，目前暂时只有轮训策略选取读库，可以配合分库分表使用。

（5.2）通过 Hint 强制指定某次查询走写库。

（5.3）如果在同一线程且同一数据库连接中有发现 DML 语句，则该 DML 之后的查询都从写库查询，DML 之前的 DQL 语句不受影响，仍然查询读库。其目的是保持同一用户线程的数据一致性。

但限于 Sharding-JDBC 本身设计的考虑，数据库层面的主从切换以及主从数据同步，Sharding-JDBC并不负责。Sharding-JDBC 定位仍然是轻量级的增强版数据库驱动。因此由于主库和从库同步延迟导致的数据不一致，并不是Sharding-JDBC 的处理范畴。

六、sharding-jdbc 3.0版本：更名为sharding-sphere

Sharding-Sphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar这3款相互独立的产品组成，详情请参考官网地址：http://shardingsphere.io/document/current/en/quick-start/。

（6.1） Sharding-JDBC

Sharding-JDBC是Sharding-Sphere的第一个产品，也是Sharding-Sphere的前身。

它定位为轻量级Java框架，在Java的JDBC层提供分库分表、读写分离、数据库治理、柔性事务等服务。它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。

（6.2） Sharding-Proxy

Sharding-Proxy是Sharding-Sphere的第二个产品。

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

Sharding-Proxy屏蔽了底层的分库分表，您可以像使用一个简单的数据库一样来操作分库分表的数据。目前提供MySQL版本，它可以使用任何兼容MySQL协议的访问客户端(如：MySQL Command Client, MySQLWorkbench等)来访问Sharding-Proxy，进而进行DDL/DML等操作来变更数据，对DBA更加友好。

七、目前分库分表的中间件有两种思想，分别是：

（7.1）类似 Sharding-JDBC 及 TDDL 的增强版 JDBC 驱动思想

（7.2）类似 Mycat 增加中间层，然后在中间层进行分库分表思想

JDBC 驱动版的优点：

1、轻量，范围更加容易界定，只是 JDBC 增强，不包括 HA、事务以及数据库元数据管理

2、开发的工作量较小，无需关注 nio，各个数据库协议等

3、运维无需改动，无需关注中间件本身的 HA

4、性能高，JDBC 直连数据库，无需二次转发

5、可支持各种基于 JDBC 协议的数据库，如：MySQL，Oralce，SQLServer

Proxy 版的优点：

1、可以负责更多的内容，将数据迁移，分布式事务等纳入 Proxy 的范畴

2、更有效的管理数据库的连接

3、整合大数据思路，将 OLTP 和 OLAP 分离处理

因此两种方式互相可以互补，建议使用 Java 的团队，且仅 OLTP 的互联网前端操作。有可能会使用多种数据库的情况，可以选择 JDBC层的中间件；如果需要 OLAP 和 OLTP 混合，加以重量级的操作，如数据迁移，分布式事务等，可以考虑 Proxy 层的中间件。

八、项目地址：

GitHub：https://github.com/shardingjdbc/sharding-jdbc

码云：https://gitee.com/shardingjdbc/sharding-jdbc