·Apache ShardingSphere 本周迎来了 5.4.0 版本的发布，该版本历时两个月，共合并了来自全球的团队和个人累计 1271 个 PR，新版本在功能、性能、测试、文档、示例等方面都进行了大量的优化。本次更新包含了不少能够提升用户体验、解决用户痛点的内容，本文与大家一起快速预览：
广播表调整为全局表
CDC 功能完善
Single table 元数据加载逻辑优化
广播表调整为全局表
广播表指所有的分片数据源中都存在的表，表结构及其数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景，例如：字典表。目前广播表只能存在于使用分片表内的数据源中。为了解决单表和广播表如果不在同一个存储节点时无法关联查询的问题，现调整为可以使用逻辑库下的全部数据源，所以需要把广播表从分片规则中移出。
新增 BroadcastRule
已有的 ShardingSphereRuleMetaData 中 rules 集合会存储 BroadcastRule
ShardingRuleConfiguration 中去掉 broadcastTables
ShardingRule 中去掉 broadcastTables
YamlShardingRuleConfiguration 中去掉 broadcastTables
CREATE BROADCAST TABLE RULE 内部逻辑调整，SQL 语句无影响
DROP BROADCAST TABLE RULE 内部逻辑调整，SQL 语句无影响
SHOW BROADCAST TABLE RULES 内部逻辑调整，SQL 语句无影响
COUNT SHARDING RULE FROM sharding_db 结果集中移除 broadcast_table 信息，SQL 语句无影响
mysql> COUNT SHARDING RULE FROM sharding_db;
+--------------------------+----------------+-------+
| rule_name | database | count |
+--------------------------+----------------+-------+
| sharding_table | sharding_db | 2 |
| sharding_table_reference | sharding_db | 2 |
| broadcast_table | sharding_db | 0 |
+--------------------------+----------------+-------+
3 rows in set (0.00 sec)新增 COUNT BROADCAST RULE (FROM sharding_db) 语句
config-sharding.yaml 配置文件中原有 SHARDING RULE 下去掉 broadcastTables 配置
config-sharding.yaml 配置文件中新增 BROADCAST RULE 配置广播表
新增 YamlBroadcastRuleConfiguration
新增 BroadcastRuleConfiguration
新增 YamlBroadcastRuleConfigurationSwapper 类实现 YamlRuleConfigurationSwapper 接口
新增 BroadcastSQLRouter 类实现 SQLRouter接口
CDC 即 Change Data Capture（变更数据捕获），是数据库的常见功能，大部分关系型数据库也都提供了 CDC 功能，比如：MySQL、PostgreSQL、openGauss 等。变更包括记录的增删改，也可能是结构的变化。CDC 系统捕获到变更数据之后，分发给订阅变更数据的下游，再写入其它系统，比如：OLTP、OLAP 或者 MQ 系统。CDC 可用于数据同步，也可用于 ETL。
ShardingSphere 5.4.0 主要有如下两个方面的优化：
纯增量模式可以在创建 CDCClient 的时候指定，此时 CDC 会跳过全量数据同步阶段，并尽早的初始化增量的位点。
StartCDCClientParameter parameter = new StartCDCClientParameter();
// full 的值默认就是 false，表示只订阅纯增量数据
parameter.setFull(false);
......
new CDCClient(parameter, records -> {
}).start();为了保证同一事务的数据可以完整的输出到客户端，对 CDC 的增量阶段进行了优化，尽量保证物理库级别的事务完整输出。
场景 A 所有的数据库都能支持。
场景 B 是一个 XA 事务，多个物理数据库之间的是互相独立的，目前只支持 openGuass。
openGauss 提供了 GLT 组件，确保在同一个 XA 事务中，多个数据库实例的 CSN 是一样的。CDC 在输出数据的时候，根据 CSN 进行排序，保证了 XA 事务的顺序。
CSN（Commit Sequence Number）：待提交事务的序列号，在 openGauss 内部使用 CSN 作为逻辑时间戳，模拟数据库内部的时序。
GLT：全局逻辑时钟，维护了 next CSN，ShardingSphere 会统一下发 CSN 到 openGauss 实例，确保任意两个事务之间的可见性在各分片上是一致的。
从 5.0 版本开始，ShardingSphere 能够自动的扫描单表（非分片表）和记录单表元数据，在用户执行相关 SQL 时进行正确的路由。但是，由于应用环境的复杂性，一些用户场景中出现了大量单表的情况，导致了以下问题：
启动速度变慢（元数据扫描耗时较长）
占用内存增多（大量单表和元数据对象）
经过分析，出现大量单表的主要原因有：
ShardingSphere 管理的数据源较多，但一部分表与当前业务无关
历史项目迭代，遗留的单表过多
考虑到该问题的普遍性，我们设计了一种新的机制，允许用户按需导入单表，避免启动阶段或者执行 REGISTER STORAGE UNIT 时自动加载过多单表元数据。从 5.4.0 版本开始，用户可以根据需要进行单表加载的管理，新增的 YAML 配置和 DistSQL 语句如下：
YAML
# YAML 配置
databaseName: sharding_db
- !SINGLE
tables:
# MySQL 模式
- ds_0.t_single
- ds_2.*
- "*.*"
# PostgreSQL, openGauss 支持指定 schema
- ds_1.public.t_config
- ds_1.public.*
- ds_1.*.*
- "*.*.*"
# 既存，控制 CREATE TABLE 路由
defaultDataSource: ds_0DistSQL
-- MySQL
LOAD SINGLE TABLE ds_0.t_single;
LOAD SINGLE TABLE ds_0.*;
LOAD SINGLE TABLE *.*;
-- PostgreSQL, openGauss
LOAD SINGLE TABLE ds_0.public.t_single;
LOAD SINGLE TABLE ds_0.public.*;
LOAD SINGLE TABLE ds_0.*.*;
LOAD SINGLE TABLE *.*.*;
-- 查看未加载的单表
SHOW UNLOADED SINGLE TABLES;
-- 查看单表及分布（既存）
SHOW SINGLE (TABLES | TABLE tableName);
-- 移除单表，格式与 LOAD 对应
UNLOAD SINGLE TABLE ds_0.t_single；特别说明：
Encrypt、Mask 等规则中已经配置的表名，如存在于单表中，自动加载
用户执行 CREATE TABLE 时，若该表为单表，自动加载
以下是调整前后的变化：
调整前：
单表无需配置
加载所有单表及其元数据
调整后：
新增单表配置和 DistSQL 语法
单表按需求加载，提高启动速度，降低内存消耗
其它规则中需要的单表，自动加载
CREATE TABLE 创建的单表，自动加载
| 元数据：Sharding 广播表调整为全局表类型 |
| JDBC：全局规则移除叹号 ! |
| DistSQL：Encrypt DistSQL 中 ASSISTED_QUERY、LIKE_QUERY 关键字简化 |
| DistSQL：SQL_PARSER RULE 语法更新 |
| 加密：加密 API YAML 配置调整，以区分加密、LIKE、辅助查询列的差异 |
| 加密：移除明文列 & queryWithCipherColumn 切换开关 |
| 读写分离：API 优化调整 |
| Proxy：移除配置项 proxy-instance-type |
| Proxy：移除配置项 proxy-backend-executor-suitable |
| Proxy：移除配置项 proxy-mysql-default-version |
| Scaling：CDC commit/rollback streaming 替换为 drop streaming |
| 【实验性功能】数据分片缓存规则合并到数据分片规则中 |
DistSQL：新增 SQL_FEDERATION 规则管理语句 |
Proxy：支持 Unix Domain Socket |
| Scaling：CDC 支持纯增量模式 |
| Scaling：CDC 增量数据按事务输出 |
| Scaling：CDC 支持 MySQL 和 PostgreSQL |
| Scaling：CDC 支持单表 |
| Scaling：CDC 支持 openGauss 所有字段类型 |
| Scaling：CDC 支持 openGauss 增量复制断线重连 |
| Scaling：移除 DataConsistencyCalculateAlgorithmChooser，存在加密规则的时候不兼容 |
| Scaling：优化整型主键表全量任务拆分，避免大数据量情况下耗时过长 |
| Scaling：调整 process 配置默认值，优化资源消耗 |
| Scaling：数据迁移不再需要手动执行 refresh table metadata |
| Scaling：PostgreSQL/openGauss 创建 slot 需要检查 slot 对应的 database 是否为空 |
| Scaling：一致性校验未执行完成时 result 不应该为 false，避免误导用户 |
| Scaling：CRC32_MATCH 一致性校验开启源端目标端并发计算 |
| Scaling：pipeline 作业兼容分片审计策略 |
| 元数据：ShardingSphere 元数据体系结构重构开发&新结构切换 |
| 元数据：单表元数据加载逻辑优化 |
| 元数据：支持 MySQL/PostgreSQL/openGauss 系统表空查询 |
| DistSQL：读写分离增加 transactionalReadQueryStrategy 支持 |
| DistSQL：增强算法 properties 校验 |
| 事务：增加权限校验 |
| 事务：移除 TransactionTypeHolder，只创建当前事务管理器 |
| SQL 支持度：支持单表、广播表执行 MySQL LOAD DATA, LOAD XML 语句 |
| SQL 支持度：完善 MySQL Test 程序测试结果中高优先级的 SQL |
| SQL 支持度：Oracle SQL 解析支持中文逗号 |
| 加密：加密功能支持投影子查询中包含加密字段查询 |
| 内核：为 INSERT, DELETE, UPDATE 和 SELECT 语句增加表是否存在元数据校验 |
| JDBC：ShardingSphereStatement 实现批量操作方法 |
| Proxy：前端支持 TLS |
Proxy：PostgreSQL/openGauss 协议支持处理 Flush 消息 |
Proxy：PostgreSQL 协议支持 bit 与 bool 类型 |
Scaling：修复 job 准备阶段失败后重启 job 导致的断点续传问题 |
Scaling：CDC delete 事件 record.beforeList 为空 |
Scaling：修复 openGaus 增量 mpp 插件 解析字符串中的单引号错误的问题 |
Scaling：job 结束后线程池未关闭 |
Scaling：修复 task 启动前关闭 job 的问题 |
元数据：修复了 H2 数据库加载模式元数据时区分大小写的问题 |
元数据：修复用户配置 PostgreSQL/openGauss schema name 做为逻辑库名时，出现的 object not found 异常 |
DistSQL：修复执行 SHOW DIST VARIABLE 时 check_table_metadata_enabled 的错误结果 |
加密：修复 PostgreSQL/openGauss Encrypt LIKE 小写导致的改写异常 |
分片：支持空分片条件传递给分片算法，允许用户控制空值路由 |
SQL 支持度：支持 MySQL Projection 中包含 BETWEEN AND 表达式解析 |
脱敏：修复脱敏算法 KEEP_FROM_X_TO_Y 配置相同 from-x 和 to-y 参数时错误脱敏结果 |
构建：修复错误码方言模块缺少 pgjdbc JAR 会报错 ClassNotFound 的问题 |
Proxy：修复 MySQL 协议下无法正确处理连续命令的 Sequence ID 的问题 |