前段时间，Apache ShardingSphere 核心技术团队应邀来到位于上海的 bilibili 公司总部，PMC Chair 张亮与 bilibili 的技术同学在电商非凡场景、ShardingSphere 版本能力等方面开展了深度交换和探讨。
在数据量呈爆发式增长、数据利用场景愈发多元的明天，不同平台、不同业务以及不同场景都造就了明天数据库利用碎片化的现状。而现在数据库所面临的挑战，与设计之初所面临的场景曾经截然不同。这一点，在 bilibili 电商业务增长中也有所体现。
bilibili 立足社区，通过十年多的倒退，围绕用户、创作者和内容，曾经构建起了一个源源不断产生优质视频内容的生态社区。随着用户体量的快速增长，bilibili 也逐步衍生出会员购等周边业务生态。业务线与利用场景的拓宽，也对 bilibili 技术人员在后盾数据方面的治理及利用提出了比拟大的挑战。在利用 Apache ShardingSphere 的过程中，在某些特定场景下也不可避免地遇到了一些问题。
此次交换，单方次要围绕着以下三方面开展，下文为外围探讨局部的内容整顿：
单方独特打造由 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 5.X 新生态，心愿借此机会在团队外部举办一场对于 Apache ShardingSphere 的技术分享， 欢送在公众号后盾中留下您的姓名、公司、职位、电话等信息，或扫描下方二维码增加官网小助手（ss_assistant_1），备注“走进企业”，会有专人与您对接。
在沟通过后如果单方认为产品和场景均十分匹配，Apache ShardingSphere 社区的外围团队将会走进您的企业，与各条研发线的工程师们现场沟通，解答对于 Apache ShardingSphere 的任何疑难。