Apache ShardingSphere 企业行｜走进 bilibili（apache服务器）

前段时间，Apache ShardingSphere 核心技术团队应邀来到位于上海的 bilibili 公司总部，PMC Chair 张亮与 bilibili 的技术同学在电商特殊场景、ShardingSphere 版本能力等方面展开了深度交流和探讨。

在数据量呈爆发式增长、数据应用场景愈发多元的今天，不同平台、不同业务以及不同场景都造就了今天数据库应用碎片化的现状。而如今数据库所面临的挑战，与设计之初所面临的场景已经截然不同。这一点，在 bilibili 电商业务增长中也有所体现。

此次交流，双方主要围绕着以下三方面展开，下文为核心探讨部分的内容整理：

双方共同打造由 bilibili 主导的 SQL 预热功能

在 bilibili 批量查询商品、订单的业务流程中，往往需要在链接初始过程中手动对 SQL 进行预热，以提升整体性能。但在手动预热的过程中，由于使用了 Mybatis 框架的 foreach 语法，导致不同长度参数其实无法作为一条 SQL 去进行预热。

目前 Apache ShardingSphere 可以通过 preview 看到 SQL 的执行计划，进而对 SQL 进行预热。未来计划提供单独的 SQL 预热接口，将 SQL 预热的时间合并在启动时间中，在 SQL 完成预热后，ShardingSphere 再自行启动。但由于种种原因，这类计划并不在 Apache ShardingSphere 核心研发团队的短期目标中。

Apache ShardingSphere 是一个由社区需求驱动的开源项目，目前所拥有的众多能力都是因为用户存在各自特定的需求，在开发完成后反馈给社区，逐渐演变成了如今 Apache ShardingSphere 丰富的能力。因此在 SQL 预热方面，ShardingSphere 社区积极邀请 bilibili 的技术同学参与进来，未来双方将共同完善 Apache ShardingSphere 的生态，让 Apache ShardingSphere 变得更加强大、更加易用。

随着 Apache ShardingSphere 的应用场景越来越宽泛，对于 ShardingSphere 适配于各种特殊业务场景下的能力需求也愈发高涨。在前几期走进企业的系列中，ShardingSphere 社区也充分了解到即便目前已经拥有了超过 100 多个功能模块，但是在日新月异的互联网及业务场景中，来自不同领域的企业，对于 ShardingSphere 的需求也是不尽相同的。Apache ShardingSphere 现在和未来，都将需要社区的力量共同建设。这也是 Apache ShardingSphere 社区陆续开展走进企业活动的初衷所在。

bilibili 在秒杀场景下的熔断自动化举措

随着 bilibili 电商规模的增长，电商业务为了提升用户粘性，往往会在前端采取如满减、秒杀等策略。但是在后端，当仓库扣减的性能相当于并发数并超过本身连接尺度上限时，只能在业务层面，基于 SKU 的个数，通过 DBA 手动切断连接的方式来干预。但手动干预的形式效率低，比较耗费 DBA 的精力，因此想要在 ShardingSphere-Proxy 中实现自动熔断的能力。

不过秒杀的场景太过极致，使用 Redis 依然是更好的选择。实现自动化非常简单，设定规则和阈值即可，将数据下沉到 Proxy 后也可以实现 Redis 的能力，但不论上层如何变，数据库底层是不会变的。因此熔断机制最好还是由 DBA 主动操作，否则在设定了阈值后，如果应用程序与数据库之间的链接稍微发生超时的情况，大批量事务就会被瞬间切断，极易造成业务雪崩的情况。

目前来看比较好的形式，是将各类关键信息挖掘出来后并基于 Proxy 的可视化界面展示出来，方便 DBA 实时比对和操作，而并非对其实现自动化。

Apache ShardingSphere 的注册中心

在 Apache ShardingSphere 体系中，注册中心为 Apache ShardingSphere 提供了分布式治理能力，并且对用户完全开放。因为在 Apache ShardingSphere 的体系架构中，计算节点（ShardingSphere-Proxy）是无状态的，并不提供数据存储能力。因此，用户账户及授权信息都需要被存储到注册中心内。同时，借助注册中心的能力，Apache ShardingSphere 能够将信息实时分发给集群中的多个计算节点，这将大大减少用户在使用集群时的维护成本，提升管理效率。

在集群模式下，Apache ShardingSphere 通过集成第三方注册中心组件 ZooKeeper 以及 Etcd 实现集群环境下元数据以及配置的共享，同时借助注册中心的通知协调能力，保证共享数据变更时的集群实时同步，并且业务不会感知到来自注册中心的变化。

【其它相关问题讨论】

Q：使用 JDBC 方式连接治理中心在性能上是否有损耗？

A：没有损耗，只是在初始化时候连接治理中心，在有变化的时候治理中心会下发推送。

Q：Sysbench 如何压测 Apache ShardingSphere？

A：Apache ShardingSphere 的两种部署类型 JDBC 以及 Proxy 都是使用 Sysbench 进行压测的。ShardingSphere 在 JDBC 端有一款全新设计的类似于 Sysbench 的 Java 程序，可以使用此程序去压测 JDBC 以及 Proxy，同时可以保证官方的 Sysbench 和我们所写的 Java 程序的标准是一致的。

Q：ShardingSphere 是否可以收敛连接数？

A：ShardingSphere-Proxy 可以进行连接数收敛，但收敛连接数肯定会导致性能下降，相对应要牺牲一些性能。

Q：Proxy 是否可以对慢 SQL 进行识别？

A：目前开源版本还没有此功能，因为开源版本的用户大多数是互联网企业，对于性能影响的容忍度比较低，因此探针数量比较少。

Q：ElasticJob 属于 Apache ShardingSphere 吗？

A：目前 Apache ShardingSphere 的迁移工具是使用的 ElasticJob，此外探活也可以使用 ElasticJob 进行操作。

Q：互联网企业是否在大规模使用 Proxy 模式？

A：互联网用户大部分选择了混合部署模式，在研发和性能方面使用 JDBC，使用 Proxy 进行管理。金融类客户更喜欢使用 Proxy，因为他们可以将 Proxy 看做数据库去进行统一管理，没有额外的学习成本。

Q：我们当前用的 ShardingSphere 4.1.1 版本，这个版本对事务有哪些支持？

A：官方 4.11 和当前的 5.1.0 版本都是支持 XA 分布式事务管理的，未来规划做 GTM 全局事务管理，计划在今年下半年启动。

在沟通过后如果双方认为产品和场景均非常匹配，Apache ShardingSphere 社区的核心团队将会走进您的企业，与各条研发线的工程师们现场沟通，解答关于 Apache ShardingSphere 的任何疑问。