Apache ShardingSphere 5.0.0 内核优化及升级指南

经过近两年时间的优化和打磨，Apache ShardingSphere 5.0.0 GA 版终于在本月正式发布，相比于 4.1.1 GA 版，5.0.0 GA 版在内核层面进行了大量的优化。首先，基于可插拔架构对内核进行了全面改造，内核中的各个功能可以任意组合并叠加使用。其次，为了提升 SQL 分布式查询能力，5.0.0 GA 版打造了全新的Federation 执行引擎，来满足用户复杂的业务场景。此外，5.0.0 GA 版在内核功能 API 层面也进行了大量优化，旨在降低用户使用这些功能的成本。本文将为大家详细解读 5.0.0 GA 版中的这些重大内核优化，并将对比两个 GA 版本中存在的差异，以典型的数据分片、读写分离和加解密整合使用的场景为例，帮助用户更好地理解这些优化并完成版本升级。

端正强

SphereEx 高级中间件开发工程师，Apache ShardingSphere Committer。

2018 年开始接触 Apache ShardingSphere 中间件，曾主导公司内部海量数据的分库分表，有着丰富的实践经验；热爱开源，乐于分享，目前专注于 Apache ShardingSphere 内核模块开发。

可拔插架构内核

Apache ShardingSphere 5.0.0 GA 版提出了全新的 Database Plus 理念，目标是构建异构数据库上层标准和生态，为用户提供精准化和差异化的能力。Database Plus 具有连接、增量、可插拔的特点，具体来说，Apache ShardingSphere 能够连接不同的异构数据库，基于异构数据库的基础服务，提供数据分片、数据加解密及分布式事务等增量功能。另外，通过可插拔平台，Apache ShardingSphere 提供的增量功能能够无限扩展，用户也可以根据需求灵活进行扩展。Database Plus 理念的出现，使得 ShardingSphere 真正意义上从一个分库分表中间件蜕变成为一套强大的分布式数据库生态系统。通过践行 Database Plus 理念，基于可插拔平台提供的扩展点，Apache ShardingSphere 内核也进行了全面地可插拔化改造。下图展示了全新的可插拔架构内核：

Apache ShardingSphere 内核流程中的元数据加载、SQL 解析、SQL 路由 、SQL 改写、SQL 执行和结果归并，都提供了丰富的扩展点，基于这些扩展点，Apache ShardingSphere 默认实现了数据分片、读写分离、加解密、影子库压测及高可用等功能。

按照扩展点是基于技术还是基于功能实现，我们可以将扩展点划分为功能扩展点和技术扩展点。Apache ShardingSphere 内核流程中，SQL 解析引擎及 SQL 执行引擎的扩展点属于技术扩展点，而元数据加载、SQL 路由引擎、SQL 改写引擎及结果归并引擎的扩展点属于功能扩展点。

SQL 解析引擎扩展点，主要包括 SQL 语法树解析及 SQL 语法树遍历两个扩展点。Apache ShardingSphere 的 SQL 解析引擎，基于这两个扩展点，默认支持了 MySQL、PostgreSQL、Oracle、SQLServer、openGauss 和 SQL92 等数据库方言的解析和遍历。用户也可以基于这两个扩展点，实现 Apache ShardingSphere SQL 解析引擎暂不支持的数据库方言，以及开发诸如 SQL 审计这样的新功能。

SQL 执行引擎扩展点按照不同的执行方式来提供扩展，目前 Apache ShardingSphere SQL 执行引擎已经提供了单线程执行引擎和多线程执行引擎。单线程执行引擎主要用于处理包含事务的语句执行，多线程执行引擎则适用于不包含事务的场景，用于提升 SQL 执行的性能。未来，Apache ShardingSphere 将基于执行引擎扩展点，提供诸如 MPP 执行引擎在内的更多执行引擎，满足分布式场景下 SQL 执行的要求。

基于功能扩展点，Apache ShardingSphere 提供了数据分片、读写分离、加解密、影子库压测及高可用等功能，这些功能根据各自需求，实现了全部或者部分功能扩展点，并且在功能内部，又通过细化功能级扩展点提供了诸如分片策略、分布式 ID 生成及负载均衡算法等内部扩展点。下面是 Apache ShardingSphere 内核功能实现的扩展点：

• 数据分片：实现了元数据加载、SQL 路由、SQL 改写和结果归并的全部功能扩展点，在数据分片功能内部，又提供了分片算法、分布式 ID 等扩展点；

• 读写分离：实现了 SQL 路由的功能扩展点，功能内部提供了负载均衡算法扩展点；

• 加解密：实现了元数据加载、SQL 改写和结果归并的扩展点，内部提供了加解密算法扩展点；

• 影子库压测：实现了 SQL 路由的扩展点，在影子库压测功能内部，提供了影子算法扩展点；

• 高可用：实现了 SQL 路由的扩展点。

基于这些扩展点，Apache ShardingSphere 功能的可扩展空间非常大，像多租户和 SQL 审计等功能，都可以通过扩展点无缝地集成到 Apache ShardingSphere 生态中。此外，用户也可以根据自己的业务需求，基于扩展点完成定制化功能开发，快速地搭建出一套分布式数据库系统。关于可插拔架构扩展点的详细说明，可以参考官网开发者手册：

https://shardingsphere.apache.org/document/current/cn/dev-manual/

综合对比来看，5.0.0 GA 版可插拔架构内核和 4.1.1 GA 版内核主要的差异如下：

版本	4.1.1 GA	5.0.0 GA
定位	分库分表中间件	分布式数据库生态系统
功能	提供基础功能	提供基础设施和最佳实践
耦合	耦合较大，存在功能依赖	相互隔离，互无感知
组合使用	固定的组合方式，必须以数据分片为基础，叠加读写分离和加解密等功能	功能自由组合，数据分片、读写分离、影子库压测、加解密和高可用等功能可以任意叠加组合

首先，从项目定位上来看，5.0.0 GA 版借助可插拔架构实现了从分库分表中间件到分布式数据库生态系统的转变，各个功能都可以通过可插拔架构融入到分布式数据库生态系统中。其次，从项目功能上来看，4.1.1 GA 版只提供一些基础功能，而 5.0.0 GA 版则更加侧重于提供基础设施，以及一些功能的最佳实践，用户完全可以舍弃这些功能，基于内核基础设施开发定制化功能。从功能耦合的角度来看，5.0.0 GA 版的内核功能，做到了相互隔离，互无感知，这样可以最大程度地保证内核的稳定性。最后，从功能组合使用的角度来看，5.0.0 GA 版实现了功能的层级一致，数据分片、读写分离、影子库压测、加解密和高可用等功能，可以按照用户的需求任意组合。而在 4.1.1 GA 版中，用户在组合使用这些功能时，必须以数据分片为中心，再叠加使用其他功能。

通过这些对比可以看出， 5.0.0 GA 版可插拔内核进行了全方位地增强，用户可以像搭积木一样对功能进行叠加组合，从而满足更多业务需求。但是，可插拔架构的调整也导致了内核功能的使用方式出现了很大的变化，在文章的后续内容中，我们会通过实例来详细介绍在 5.0.0 GA 版中如何组合使用这些功能。

Federation 执行引擎

Federation 执行引擎是 5.0.0 GA 版内核的又一大亮点功能，目标是支持那些在 4.1.1 GA 版中无法执行的分布式查询语句，例如：跨数据库实例的关联查询及子查询。Federation 执行引擎的出现，使得业务研发人员不必再关心 SQL 的使用范围，能够专注于业务功能开发，减少了业务层面的功能限制。

上图展示了 Federation 执行引擎的处理流程，总体上来看，仍然是遵循着 SQL 解析、SQL 路由、SQL 改写、SQL 执行这几个步骤，唯一的区别是 Federation 执行引擎额外引入了 SQL 优化，对分布式查询语句进行 RBO（Rule Based Optimizer） 和 CBO（Cost Based Optimizer） 优化，从而得到代价最小的执行计划。在 SQL 路由阶段，路由引擎会根据 SQL 语句是否跨多个数据库实例，来决定 SQL 是否通过 Federation 执行引擎来执行。

Federation 执行引擎目前处于快速开发中，仍然需要大量的优化，还是一个实验性的功能，因此默认是关闭的，如果想要体验 Federation 执行引擎，可以通过配置 sql-federation-enabled: true 来开启该功能。

Federation 执行引擎主要用来支持跨多个数据库实例的关联查询和子查询，以及部分内核不支持的聚合查询。下面我们通过具体的场景，来了解下 Federation 执行引擎支持的语句。

• 跨库关联查询：当关联查询中的多个表分布在不同的数据库实例上时，由 Federation 执行引擎提供支持。

例如，在下面的数据分片配置中，t_order 和 t_order_item 表是多数据节点的分片表，并且未配置绑定表规则，t_user 和 t_user_role 则是分布在不同的数据库实例上的单表。

rules:
- !SHARDING
  tables:
    t_order:
      actualDataNodes: ds_${0..1}.t_order_${0..1}
      tableStrategy:
        standard:
          shardingColumn: order_id
          shardingAlgorithmName: t_order_inline
    t_order_item:
      actualDataNodes: ds_${0..1}.t_order_item_${0..1}
      tableStrategy:
        standard:
          shardingColumn: order_id
          shardingAlgorithmName: t_order_item_inline

由于跨多个数据库实例，下面这些常用的 SQL，会使用 Federation 执行引擎进行关联查询。

SELECT * FROM t_order o INNER JOIN t_order_it