共计 1810 个字符，预计需要花费 5 分钟才能阅读完成。
前段时间，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 的任何疑难。