ShardingSphere 在东南亚｜与科技保险公司 Fuse 的技术融合

Apache ShardingSphere 核心技术团队前段时间去到 Fuse InsurTech 中国研发中心，PMC Chair 张亮与 Fuse 的技术同学在开源生态建设、分布式事务、慢 SQL 等话题方面展开了深度交流。

作为东南亚领先的保险科技公司，Fuse 拥有独特的价值定位，通过整合保险产业链、重塑价值流进而构建高效的线上分销平台，为传统销售渠道赋能的同时让保险惠及更多的大众群体。随着用户覆盖数量以及接入平台中的各保险供应商数量的增加，Fuse 采用 Apache ShardingSphere 来缓解底层数据库压力并提升后台响应性能，同时也对多种类数据进行了细粒度管理。

使用 ShardingSphere 建表的优势？

建表的形式 ShardingSphere 不对用户做强制要求，可以通过 ShardingSphere 建表，也可以自建表。如果采用 Apache ShardingSphere 进行建表，只需执行一条 SQL 就可以实现自动扩容，并且用户无需感知和关注扩容过程，进而为用户带来一站式服务的体验。

另一方面如果是用户自建表，也可以与 ShardingSphere DistSQL 的能力相结合。通过将 add resource 注册到 ShardingSphere 之中，随后用户只需修改分片规则即可。因为在 add resource 之后，ShardingSphere 会默认所有的表都是没有分库的表。以 create sharding table rule 为例，换成 alter sharding table rule，同样可以实现自动扩容。

另外，如果用户认为使用 ShardingSphere 相对比较黑盒，后续 ShardingSphere 的扩容组件 Scaling 也会独立出来，成为一个独立的管道方便大家使用。

目前开源版本如何支持分布式事务？

目前支持的分支事务会分为两种，分别为 XA 以及柔性事务。不过在使用过程中，由于性能没有 XA 高，因此使用柔性事务的感受不如使用 XA 的感受好。如果用户认为分布式事务性能不是瓶颈问题，使用 XA 完全足够了。

因为使用 XA 也会带来一些小问题，比如 XA 只是分布式事务，但不是全局事务，无法做到面向事务的全局有序，会在一些特定情况下损失部分事务的一致性。也就是说它不能做到事务的全局有序，会在一定的情况下会损失一部分事物的一致性；另一方面，XA 的修复日志会存储在 ShardingSphere 本地，如果修复日志丢失，数据也有可能会丢失。

在分布式情况下，面对事务要保留一定的处理空间，特别是在数据库之上往往会遇到各种各样的场景，需要根据业务的实际使用需求来定制化，如果过多涉及分布式事务的处理，节点与节点之间过于频繁的通信，一定会对性能产生更多额外的损耗，并拉长整体的处理时间。

目前 Apache ShardingSphere 提供 XA 柔性事务集成方案，在 ACID 事务中对隔离性的要求很高，在事务执行过程中，必须将所有的资源锁定。柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面上移至业务层面，通过放宽对强一致性要求，来换取系统吞吐量-+的提升。

未来 SphereEx 也会做一个新的事务引擎 GTM，GTM 引擎会完全使用全局事务的方式来实现，因此会提升 XA 的使用体验和性能。

实现数据分片后，如何让查询能够覆盖各个维度？

使用分片键做查询肯定是性能最快的。另一种方式是不带分片键，以全路由的形式来查询，这种方式性能就会相对较差。目前 ShardingSphere 也在规划实现二级索引，将各种查询维度做成索引，相当于这些索引里就是查询维度的分片，将索引以及对应的 ID 存储起来，以空间换取时间，通过索引将查询实现转换，避免以打全片路由的方式来查询，进而提升查询性能。

另一方面，ShardingSphere 即使采用全片路由后的效率也并不是大家理解中的那么低。尤其是在多个分表的情况下，ShardingSphere 会把过去在一个表里的操作换成面向多个表的操作，因此性能的差距并不大，用户可以通过实际测试来找到最佳的应用方案。总体来说，不使用分片键，采用二级异构索引或全路由的形式，性能方面也是相对可控的。

在业务中如何配合使用 ShardingSphere 注册中心

目前是 ZooKeeper 或者 Etcd 都是可以的。然后它用来存储 ShardingSphere 的元数据，包括了数据库的库表结构，然后还有 ShardingSphere 的分片加密、读写分离的各种规则信息。然后也会记录在整个分布式的情况下 ShardingSphere 集群状态和数据库状态，以及状态的下发和通知这些主要的能力。同时，借助注册中心的能力，Apache ShardingSphere 能够将信息实时分发给集群中的多个计算节点，这将大大减少用户在使用集群时的维护成本，提升管理效率。

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

此外，如果使用了其它注册中心也可以快速接入到 ShardingSphere 中来。因为 ShardingSphere 中所有的能力都是可插拔插件，不论是何种注册中心，均可以通过 ShardingSphere 的接口来实现的，并且不用修改内核代码。

针对慢 SQL 的报警、监控、治理等问题

对于使用开源版本的用户来说，可以通过 metrics 从 Prometheus 中拿到这些数据，再以各种可视化的形式展现出来。此外，SphereEx 公司研发了一款可视化管理工具 SphereEx-Console，以探针的方式收集 ShardingSphere 各种 metrics 信息，然后把这些 metrics 信息打到 Prometheus 中，再通过 Prometheus 展现出来。并且 SphereEx-Console 中的指标会比开源版会更多一些。

如何在生产环境中引入 ShardingSphere

如果此前业务环境中没有部署过 ShardingSphere，只需要在业务的低峰期，将生产环境中部署的集群由访问数据库改为 ShardingSphere 即可，此时可以先不执行分片策略，接入完成之后再修改相应的分片规则。这个过程中就会涉及到扩容以及数据迁移。期间，ShardingSphere 会将存量数据自动迁移过去，为了确保数据一致性，ShardingSphere 提供了多种内置的数据一致性校验算法，用以比较源端数据和目标端数据是否一致，默认使用 CRC32 以便在速度与一致性上取得平衡，且校验算法支持 SPI 自定义。

Apache ShardingSphere 提供了多种内置的数据一致性校验算法，用以比较源端数据和目标端数据是否一致，默认使用 CRC32 以便在速度与一致性上取得平衡，且校验算法支持 SPI 自定义。

在数据迁移构成中，数据体量越大耗时越长，同时增量数据往往是动态变化的，为了最终确认两端数据一致，一定是需要一段停写时间，让日志能够追上来并完成校验。而对于性能的影响，则在于这段停写时间的长短。

Apache ShardingSphere 可以将数据迁移任务分为多个部分并行执行，合并同一记录的修改操作，在配置上之后再执行一条命令停止主库的写入，使主库只具备只读的权限，同时在只读期间暂停 SQL 执行并在停写的瞬间确保数据是全局一致的，进而再操作切库，减少对于系统可用性的影响。

【联系我们】

如果您在业务中有应用 Apache ShardingSphere，想要快速了解、接入 Apache ShardingSphere 5.X 新生态，希望借此机会在团队内部举办一场关于 Apache ShardingSphere 的技术分享，欢迎在公众号后台中留下您的姓名、公司、职位、电话等信息，或扫描下方二维码添加官方小助手（ss_assistant_1），备注“走进企业”，会有专人与您对接。

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

欢迎点击链接，了解更多内容：
Apache ShardingSphere 官网：https://shardingsphere.apache.org/

Apache ShardingSphere GitHub 地址：https://github.com/apache/shardingsphere

SphereEx 官网：https://www.sphere-ex.com