Apache ShardingSphere-Proxy与PolarDB多主集群（库表）结合使用最佳实践

原理介绍

Apache ShardingSphere是开源的分布式数据库增强计算引擎，通过在应用和数据库之间部署ShardingSphere-Proxy代理，来实现非应用侵入式的分库分表。

PolarDB多主集群（库表）通过将不同的逻辑数据库分散至不同的主节点（RW），来实现读写能力水平扩展。

ShardingSphere-Proxy结合PolarDB多主集群（库表），将数据通过ShardingSphere分散至多个数据库，再结合PolarDB多主集群（库表）实现读写能力扩展。原理图如下所示：

• 如果仅使用ShardingSphere，在需要提升数据库集群读写能力时，需要先使用传统数据库运维手段进行数据复制和备份恢复，再配合业务系统停写、规则切换、数据验证、业务系统恢复等步骤来提升数据库集群的读写能力，其中，数据库的运维操作尤为复杂耗时。

• 使用PolarDB多主集群（库表）之后，您可以省去绝大部分手工扩展数据库集群的工作，您只需要通过控制台或OpenAPI为PolarDB多主集群（库表）增加节点，然后在业务低峰期，执行ALTER DATABASE name POLARDB_WRITE_NODE x等操作，即可在数秒内将数据库集群的读写扩展到新增的节点上，大幅减少了数据库停写维护的时间，提高了业务系统的SLA。

  PolarDB多主集群（库表）在执行ALTER DATABASE name POLARDB_WRITE_NODE x切换数据库所在的主节点时，目标数据库会有秒级的不可访问，显示为查询阻塞或获取表全局锁失败错误。如果能够在切换节点期间避免访问该数据库，或者避免访问该库的查询阻塞过久抢占访问其他库的资源，均可以减少切换数据库所在的RW节点时对业务的影响。

  • 切换节点期间，避免访问切换中的数据库。

    ShardingSphere借助注册中心实现集群管理，在/metadata/${schemeName}/dataSources路径下，记录了一个逻辑库的数据源。ShardingSphere会感知该路径值的变化，并动态更新和重建相关连接池。通过联动注册中心配置变更和PolarDB进行多主集群（库表）的弹性扩容，先禁用指定的数据源，再执行ALTER DATABASE，最后再恢复数据源。您可以将业务影响控制在预期范围（只影响与需要迁移的数据库相关的查询）的情况下获得接近线性的数据库读写能力扩展。

  • 切换节点期间，避免访问切换中的数据库时查询阻塞过久。

    使用JDBC URL配置ShardingSphere的数据源，您可以在URL中配置connectTimeout和socketTimeout参数。通过将这两个超时时长配置为500ms，也可以使访问到正在切换的数据库的查询，尽可能快地超时失败，从而释放线程和连接资源去访问其他数据库。

性能测试

测试环境

PolarDB多主集群（库表）包含4个数据库，4个RW节点（4C16GB），ShardingSphere-Proxy以内存模式部署于ECS，ShardingSphere-Proxy提供1个逻辑库4张逻辑表，每张逻辑表均按id%4散列于PolarDB多主集群（库表）的4个数据库。

测试过程

初始状态下，4个数据库全部负载于其中一个RW节点，使用Sysbench启动2048个线程对所有逻辑表执行基准测试。测试期间，将3个数据库依次切换至空闲的RW节点，最终每个RW节点上均有且仅有一个数据库，查看集群整体的性能变化趋势。

• 如果业务的写入以自动提交（autoCommit=1）为主，PolarDB多主集群（库表）结合ShardingSphere-Proxy可以实现接近线性的性能提升。

  • 配置较短的超时时间。

    • QPS与MPS：

    • TPS与CPU使用率：

  • 联动注册中心。

    • QPS与MPS：

    • TPS与CPU使用率：

• 如果业务的写入以显式事务（autoCommit=0）为主，PolarDB多主集群（库表）结合ShardingSphere-Proxy可以实现仅次于线性的性能提升。以256个线程进行写入测试，弹性扩容效果如下：

  • 配置较短的超时时间。

    • QPS与MPS：

    • TPS与CPU使用率：

  • 联动注册中心。

    • QPS与MPS：

    • TPS与CPU使用率：