深度认识 Sharding-JDBC：做最轻量级的数据库中间层

Sharding-JDBC 的设计初衷是想提供一个数据库中间层，用于透明的处理分库分表，而无需业务开发人员在业务代码中根据分片键生成 SQL。

第一版的分库分表并不是现有的 Sharding-JDBC，而是当当的一个内部框架 ddframe 的数据库模块，dd-rdb 的其中一项功能就是分库，没有分表功能，当时只是做了简单的 SQL 解析。后来随着 ddframe 被各个团队采用，只分库的需求渐渐不够用了，而 dd-rdb 里面有大量的数据库 ORM 相关的东西，为了使分库分表这一核心需求更加纯粹，我们才将其中的分片的部分单独提炼出来并命名为 Sharding-JDBC，用于在 Java 的 JDBC 层面提供一层驱动，无缝的处理这方面的需求。

对于关系型数据库数据量很大的情况，需要进行水平拆库和拆表，这种场景很适合使用 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 数据库访问层，并且无缝的接入业务应用。

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

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

在 osgit 上有性能测试文档。单库的场景下，由于需要进行 SQL 解析以及路由，器性能损失是 0.02%。双库的场景下，采用了分布式的方式存取数据，性能提升越 94%。

目前和 Sharding-JDBC 这种基于 JDBC 层架构类似的，据我所知只有 TDDL，而 TDDL 并未将分库分表这块开源。基于 JDBC 层进行分片的好处是轻量、简单、兼容性好以及无需额外的运维工作。缺点是无法跨语言，目前仅支持 Java。

现在暂时未考虑集成 SparkSQL 或者 Hive。因为 Sharding-JDBC 的定位还是关系型数据库中间层，为了稳定性的考虑，不会改变数据库的存储引擎。未来我们会做基于 Proxy 版本的 Sharding-JDBC-Server，会渐渐的考虑将 Spark 等大数据的查询方式引入进来。

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

SQL 解析这块，现在的 Shariding-JDBC 和 Mycat 也比较相似，都是使用 Druid 作为 SQL 解析的基础类库。但 Sharding-JDBC 正在重写 SQL 解析这块，是去掉 Duird 的完全自研版本。不可否认 Druid 是一个优秀的连接池，而且 SQL 解析这块做得也很强，但它毕竟不是一个专门为了 Sharding 而做的 SQL 解析器，它的大致解析流程是 Lexer -> Parser -> AST -> Vistor，使用者需要实现它的 Vistor 接口，将自己的业务逻辑在 Vistor 中实现，因此需要通过 Vistor 再生成 SharidingContext，而抽象语法树 AST，也需要对 SQL 完全理解。Sharding-JDBC 自研的 SQL 解析器，对于 Sharding 不相关的关键词采用跳过的方法，整体解析流程简化为 Lexer -> Parser -> SharidingContext，在性能以及实现复杂度上都有所突破。

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

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

另外由于 Sharding-JDBC 本身是分库分表中间件，读写分离也是后加入的功能，因此可以支持分库分表+读写分离，但是仅读写分离目前还不容易配置，未来也会将读写分离提炼出来作为独立的 API 使用。

是的，可以支持。Shariding-JDBC 本意就是只做分片 + 读写分离，连接池应该交由连接池去处理，各做各的互不影响。

• 分库分表使用 like 查询是有限制的。目前 Shariding-JDBC 不支持 like 语句中包含分片键，但不包含分片键的 like 语句可以正确执行。

• 至于 like 性能问题，是与数据库相关的，Shariding-JDBC 仅仅是解析 SQL 以及路由至正确的数据源而已。

• 是否会查询所有的库和表是根据分片键决定的，如果 SQL 中不包括分片键，就会查询所有库和表，这个和是否有 like 没有关系。

目前 Sharding-JDBC 还没来得及做配置界面。目前主要集中于以 jar 包的形式提供服务，和业务应用一起发布，旨在简化开发，对 DBA 无影响，因此 DBA 看到的还是分库后的零散的数据库。

未来会做配置中心，用于动态的修改分片数据源，也会配套的提供管理界面。未来还会将数据库的 Metadata 统一管理起来，为 DBA 提供更加友好的服务。

读写分离的文档地址：http://dangdangdotcom.github.io/sharding-jdbc/post/master_slave/

大致使用方式如下：

因为 Sharding-JDBC 是一个 jar，它与业务应用的生命周期是一致的，同生同死。因此只要解决好使用 Sharding-JDBC 的业务系统的鲁棒性就可以了。

碎片化库表的问题，即使不用 Shariding-JDBC 分库分表，也会同样存在的，Shariding-JDBC 确实没处理这块，不过也不会更加恶化。

等核心稳定后，未来会考虑为 DBA 做运维工具。

Sharding-JDBC 自研的 parser 是开源的，目前在 parser 这个分支，但是还未做完，仍然在快速的迭代中。

SQL 解析原理和 Druid 基本相同，但是简化了一些流程。Duird 的初衷是对 SQL 进行监控、分析以及规范化，因此它的 SQL 解析场景需要对 SQL 进行完全的理解。采用 Druid 的作为基础解析器的 Sharding-JDBC 解析流程为：（Lexer -> Parser -> AST -> Vistor） -> SharidingContext，其中括号内是 Duird 框架的流程，无法修改。而 Sharding-JDBC 仅需理解与 Sharding 相关的关键字，无关内容则采取跳过的方式，因此将直接生成分片上下文，无需再通过抽象语法树的访问器再获取。

New Parser 的解析流程简化为：Lexer -> Parser -> SharidingContext。因此在性能以及实现复杂度上都有所突破。具体的性能测试报告目前还未做，会随着 New Parser 分支完全一起发布。

关于分库分表自动迁移的事，当当还没有做到自动化。由于数据迁移更加贴近于数据库运维工具，和 JDBC关系不大，因此 Shariding-JDBC 也暂时未将数据迁移纳入范围。

Sharding-JDBC 目前正在进行 SQL Parser 部分的重写。之前的 Sharding-JDBC 使用 Duird 作为 SQL 解析的基础工具，但基于各方面的考虑，我们决定采用自研的方式解析 SQL，能进一步的提升性能和 Sharding 的准确性以及兼容性。

New SQL Parser 完成之后，我们会着重处理之前没有完成的柔性事务 TCC 部分，更多类型 SQL 的支持以及配置动态化。

这些做完之后会考虑将 Sharding-JDBC 分为 Sharding-Driver 以及 Sharding-JDBC-Server 两个版本，用于满足不同用户的需要。Sharding-JDBC-Driver 会更加轻量级，而 Sharding-JDBC-Server 会以 Proxy 的形式提供服务，能更好的处理数据迁移，事务以及 OLAP 等需求。

Shariding-JDBC 的核心应该就是 JDBC 驱动的增强，以 jar 形式提供轻量级的服务。大体上看，Sharding-JDBC 的生态应该大致分为 3 个环路：

有很多朋友提到关于对其他语言的支持，因为 Shariding-JDBC 是基于 Java 提供的 JDBC 规范的接口所开发，因此目前暂时不支持 Python、Node.js 等。

但其核心的解析、路由、结果归并等功能模块和基于 Proxy 版本开发几乎是一致的。因此，未来我们有打算提供 Shariding-JDBC-Server 版本，将会支持全语言。

有朋友看到我们在考虑开发 Sharding-JDBC-Server，以为目前的 Sharding-JDBC 模式遇到了某些不可解决的问题。其实 Shariding-JDBC 以当前的定位来说，没有遇到不可解决的问题，但如果想做的更多（前面提到的数据迁移，分布式事务，元数据管理等），则需要向 Proxy 的方式靠拢。Shariding-JDBC 想提供两种不同的使用方式，给使用者更自由的选择。

还有就是对 SQL 语句的支持。由于时间和精力有限，目前无法做到全 SQL 的兼容。我们现阶段的目标是尽量支持 OLTP 最常用的 80% 的 SQL。目前支持聚合、分组、排序等查询。暂时不支持 distinct，对 or 的支持也不是特别完善，但是 distinct 和 group by 可以互换，or 也可以用 in 代替。因此绝大部分 SQL 经过修改是可以使用的。

有朋友提到，既然 distinct 和 group by 可以互换，or 可以用 in 代替，那么是不是可以考虑直接在 SQL 解析的时候自动切换？

对于这个问题，虽然这样做在技术上是可行的，但是设计上来说还有待商榷。

如果已经做了 distinct 和 or 的解析，其实完全没有必要改写 SQL，直接支持就可以了。而改写 SQL，对于 DBA 的调试就比较痛苦，因此我们希望做到尽量不修改 SQL，仅修改必要的部分，如：分表的名称、avg 转化为 count 和 sum、limit 的 offset 和 rowCount。

对于过于复杂的 SQL，如子查询等，不一定适合在大数据量的分片数据库中使用，也许需要重新梳理。

未来我们也会对 SQL 兼容性这块持续进行提升。

目前 Sharding-JDBC 仅支持 MySQL，对其他数据库的支持（比如 Oracle）也正在进行。现在 New SQL Parser 正在进行中。计划在这个版本发布对 Oracle、PG 以及 SQLServer 的支持。对于 Oracle 以及 SQLServer 主要的支持在于特殊关键词识别和分页。

New SQL Parser 确实工作量比较大，虽然目前整体代码已经梳理得差不多了，但想稳定的提供服务还需要一些时间。预计 4 月份提供 snapshot，6 月份提供稳定版。

New SQL Parser 在 Git 的 parser 分支持续更新中，欢迎继续关注。

jsqlparser 用的是 JavaCC 的方式解析 SQL，相对于 Druid 来说，性能比较低。正则解析的话，性能应该会更低，而且这两种方式都比较难调优。

Druid 采用的词法和语法分析的方式解析 SQL，编码工作量大，但性能会提升很多。Druid 的 SQL 解析器对于开发者而言稍微有些不易上手。Shariding-JDBC 采用与 Druid 相同的 SQL 解析方式，但为 Sharding 做了优化。

只是获取表名的话，jsqlparser 和 Duird 都没问题，如果考虑性能问题，还是建议用 Druid 或者参考下 Sharing-JDBC 的做法。

分布式事务这块，我们认为 XA 多阶段提交的方式，虽然对分布式数据的完整性有比较好的保障，但会极大的降影响应用性能，并未考虑采用。我们采用的是两种方式，一种称之为弱 XA，另一种是柔性事务，即 BASE。

弱 XA 就是分库之后的数据库各自负责自己事务的提交和回滚，没有统一的调度器集中处理。这样做的好处是天然就支持，对性能也没有影响。但一旦出问题，比如两个库的数据都需要提交，一个提交成功，另一个提交时断网导致失败，则会发生数据不一致的问题，而且这种数据不一致是永久存在的。

柔性事务是对弱 XA 的有效补充。柔性事务类型很多。

Sharding-JDBC 主要实现的是最大努力送达型。即认为事务经过反复尝试一定能够成功。如果每次事务执行失败，则记录至事务库，并通过异步的手段不断的尝试，直至事务成功（可以设置尝试次数，如果尝试太多仍然失败则入库并需要人工干预）。在尝试的途中，数据会有一定时间的不一致，但最终是一致的。通过这种手段可以在性能不受影响的情况下牺牲强一致性，达到数据的最终一致性。最大努力送达型事务的缺点是假定事务一定是成功的，无法回滚，因此不够灵活。

还有一种柔性事务类型是 TCC，即 Try Confirm Cancel。可以通过事务管理器控制事务的提交或回滚，更加接近原生事务，但仍然是最终一致性。其缺点是需要业务代码自行实现 Try Confirm Cancel 的接口，对现有业务带来一定冲击。未来 Sharding-JDBC 会带来对 TCC 的支持。

还有一些其他的分布式事务，如 Google 提出的 F1 等，由于 Shariding-JDBC 仍然使用数据库的原有存储引擎，并未改变，因此暂时不考虑对此类型事务的支持。

分库分表分为水平拆分和垂直拆分。按照业务分库或分表属于垂直拆分。水平拆分是将同样的库或表按照一定的分片规则拆成多个。

分库和分表都可以有效的处理由于数据量大而导致的查询性能下降的问题。分库还可以缓解高并发对数据库带来的压力，但仅分表可以使用本地事务代替分布式事务。因此分库和分表的合理使用是需要根据业务场景来决定的。

Sharding-JDBC 作为开发的基础类库，支持分库和分表，将选择的余地留给业务开发的工程师。

如果用户名是主键，则可以直接根据您定义的分片策略计算，算出该用户最终落在哪个库的哪张表上。

如果用户名不是主键，则必须通过全路由查询，一个一个的找，直到找到为止。

这个问题比较大，需要从整体的角度来讨论一下。

MySQL + 开源分片中间件是公司将技术核心抓在了自己的手里，互联网公司大多愿意采用。这个不仅是眼前的经济成本问题，还包括了技术问题解决成本、对业务发生变化时对技术的控制能力等。比较成熟的公司都会沉淀出适合自己的中间件架构，以及各种监控、治理等辅助系统。

NoSQL 也是一种选择，但它们的定位是关系型数据库的有益补充，并不是要完全替换掉关系型数据库，因此，关系型数据库 + 分片仍然有其存在价值。

对于 Oracle，我的看法是重要的业务数据可以考虑，而一些周边数据，就没什么必要。当然如果公司不差钱，定位又非技术导向，而是纯业务导向的话，完全依赖 Oracle 也是可以的。只不过 Oracle 不能满足互联网的全部场景。各种云数据库和 Oracle 差不多，公司对自我的定位很重要。如果有核心业务，完全可以把技术全包出去。

个人理解，当业务量较小或适中的情况下，采用 Oracle 和云数据库是合理的选择。而在公司的业务爆炸式增长的大型互联网公司，这些方案未可行，因为独角兽级别的公司遇到业务场景基本都是独一无二的，其解决方案并不是第三方功能能够直接给予的。成长到一定程度的公司大多会选择自研 + 开源的组合，保证其技术的适应度以及和业务的匹配度。

是的，正确。

简单说，刚起步用 MySQL；有钱并且业务量适中用 Oracle，核心业务用 Oracle，非核心业务用云数据库；资金不充足业务量较大用 MySQL + 开源中间层；业务量超大只能自研。

大数据和关系型数据库不是一个方向，主要用于存储其他类型数据了，订单、交易等数据一般不会放大数据，更适合日志，浏览记录等。

Sharding-JDBC 的服务对象是任何关系型数据库，无论是 MySQL 还是 PG。

不过针对这个问题可以再大致聊一下。很多公司的技术选型在于平衡，尤其是数据库选型这块。不一定 MySQL 就是最好的数据库，某些方面 PG 确实要更好，但 MySQL 是在各个方面受认可最多的数据库。比如周边的 MHA 套件、开发和 DBA 对数据库的熟悉程度等。因此，即使是 MySQL 的分支版本 MariaDB 或 Percona，无论功能性能再怎么提升、引擎再怎么变化，其总体的认可度也还是不如 MySQL 的。

两种方式各有优缺点。

JDBC 驱动版的优点：

Proxy 版的优点：

因此两种方式互相可以互补，建议使用 Java 的团队，且仅 OLTP 的互联网前端操作。有可能会使用多种数据库的情况，可以选择 JDBC 层的中间件；如果需要 OLAP 和 OLTP 混合，加以重量级的操作，如数据迁移，分布式事务等，可以考虑 Proxy 层的中间件。但目前开源的数据迁移和分布式事务的完善解决方案还不常见。NewSQL 这种改变数据库引擎的方式就不在这里讨论了。