Apache ShardingSphere 企业行｜走进怪兽充电（apache tomcat）

前段时间，Apache ShardingSphere 核心技术团队应邀来到位于上海的怪兽充电公司总部，PMC Chair 张亮与怪兽充电的技术同学在 ShardingSphere 场景解决方案、开源生态建设等话题方面展开了深度交流与探讨。

作为国内共享充电宝领域的领军企业之一，怪兽充电立足于整个行业，在数据分片层面早有需求。怪兽充电从 2017 年时就开始应用 Sharding-JDBC，主要应用场景是分库分表，ShardingSphere-Proxy 则主要被应用于测试场景，并没有被部署在真实生产环境当中。

怪兽充电技术团队在使用 Apache ShardingSphere 的过程中也遇到了一些问题，如需要将研发所写的分库分表策略集中在一个文件后再配置到 Proxy 中以形成一套新的数据库，在分库分表之后进行数据查写操作相对繁琐，需要额外设计许多 binlog、阈值管理等工作。在本次交流中，双方着重对以下这些使用场景展开了讨论。

如何保证加解密过程中密钥的安全性

Apache ShardingSphere 的加解密功能同分片类似，都是将使用的决策交给了用户，灵活度很高。

加密是用加密规则将数据变形，以达到安全控制目的。Apache ShardingSphere 内置了部分的加密算法以及国密算法。如果不希望 ShardingSphere 在本地配对密钥，用户可以自定义加密算法。

在性能层面，数据加解密过程是否会对业务性能产生较大的影响，其关键在于加解密算法本身。如果算法本身优化的不够好，就会拖慢数据加解密的整体效率，另一方面解密数据的力度也会对性能产生影响。一般在没有额外加密算法损耗性能的情况下，Apache ShardingSphere 加解密能力对于业务的损耗会被控制在 10% 以内。

扩容时如何减少数据的迁移量？是否考虑过一致性哈希算法？

目前 Apache ShardingSphere 在扩容方面做得还相对粗糙，是计划未来进行优化的方向之一。在当前版本中，Apache ShardingSphere 在扩容时没有考虑数据是否需要被迁移的问题，因此往往需要对所有数据进行迁移，这无疑加大了数据库扩容之外工作量。未来 ShardingSphere 将会实现更加细粒度的迁移，用户只需迁移定量的数据。此外基于 range 扩容、在固定时间建表扩容等操作，可以不做迁移操作直接扩表。

关于一致性哈希算法，这其实是分片算法的一部分。如果分片采用的是一致性哈希算法，那么数据迁移过程就相对简单。如果是 mod，那就需要将数据全部迁移或只迁移一半。另外，现在 Apache ShardingSphere 实现的是逻辑迁移，未来也在考虑实现物理迁移的方式。先做预分片，建立逻辑库，在建好的逻辑库中进行分片。如果一个数据库里建立 100 个逻辑库、分 100 片，未来扩容时只需要用物理迁移的方式将其中的 50 片迁移到新的数据库即可。

共建 ShardingSphere 开源生态

在交流过程中，发现怪兽充电的许多需求与 Apache ShardingSphere 部分规划都不谋而合。双方也约定未来将在社区层面展开合作，怪兽充电也将积极在 Apache ShardingSphere 社区中贡献自己的力量，怪兽充电自主研发了一款查询平台，依赖 information schema 里的数据来自动生成关联表。但目前 Apache ShardingSphere 在这方面的支持度还不够友好，未来怪兽充电技术团队也将与 Apache ShardingSphere 社区联系起来，共同梳理 information schema 功能实现的优先级。

此外包括订单业务下的分片键改动、数据加解密等方面的需求，后续 Apache ShardingSphere 社区也将与怪兽充电团队保持互动，进一步丰富社区生态。

【联系我们】

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

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