ShardingSphere详解 - 弹性伸缩原理
ShardingSphere详解 - 弹性伸缩原理
支持自定义分片算法,减少数据伸缩及迁移时的业务影响,提供一站式的通用弹性伸缩解决方案,是 Apache ShardingSphere 弹性伸缩的主要设计目标; 这篇文章主要转载自ShardingSphere官方 在新窗口打开 网站(V5.1.0版本)。@pdai
背景
支持自定义分片算法,减少数据伸缩及迁移时的业务影响,提供一站式的通用弹性伸缩解决方案,是 Apache ShardingSphere 弹性伸缩的主要设计目标。
对于使用单数据库运行的系统来说,如何安全简单地将数据迁移至水平分片的数据库上,一直以来都是一个迫切的需求; 对于已经使用了 Apache ShardingSphere 的用户来说,随着业务规模的快速变化,也可能需要对现有的分片集群进行弹性扩容或缩容。
挑战
Apache ShardingSphere 在分片算法上提供给用户极大的自由度,但却给弹性伸缩造成了极大的挑战。 找寻既能支持自定义的分片算法,又能高效地将数据节点进行扩缩容的方式,是弹性伸缩面临的第一个挑战;
同时,在伸缩过程中,不应该对正在运行的业务造成影响。 尽可能减少伸缩时数据不可用的时间窗口,甚至做到用户完全无感知,是弹性伸缩的另一个挑战;
最后,弹性伸缩不应该对现有的数据造成影响,如何保证数据的正确性,是弹性伸缩的第三个挑战。
ShardingSphere-Scaling 是一个提供给用户的通用数据接入迁移及弹性伸缩的解决方案。
状态
ShardingSphere-Scaling 从 4.1.0 版本开始向用户提供。 当前处于 alpha 开发阶段。
原理说明
考虑到 Apache ShardingSphere 的弹性伸缩模块的几个挑战,目前的弹性伸缩解决方案为:临时地使用两个数据库集群,伸缩完成后切换的方式实现。
这种实现方式有以下优点:
- 伸缩过程中,原始数据没有任何影响
- 伸缩失败无风险
- 不受分片策略限制
同时也存在一定的缺点:
- 在一定时间内存在冗余服务器
- 所有数据都需要移动
执行阶段说明
弹性伸缩模块会通过解析旧分片规则,提取配置中的数据源、数据节点等信息,之后创建伸缩作业工作流,将一次弹性伸缩拆解为4个主要阶段
- 准备阶段
- 存量数据迁移阶段
- 增量数据同步阶段
- 规则切换阶段
- 伸缩工作流
准备阶段
在准备阶段,弹性伸缩模块会进行数据源连通性及权限的校验,同时进行存量数据的统计、日志位点的记录,最后根据数据量和用户设置的并行度,对任务进行分片。
存量数据迁移阶段
执行在准备阶段拆分好的存量数据迁移作业,存量迁移阶段采用 JDBC 查询的方式,直接从数据节点中读取数据,并使用新规则写入到新集群中。
增量数据同步阶段
由于存量数据迁移耗费的时间受到数据量和并行度等因素影响,此时需要对这段时间内业务新增的数据进行同步。 不同的数据库使用的技术细节不同,但总体上均为基于复制协议或 WAL 日志实现的变更数据捕获功能。
- MySQL:订阅并解析 binlog
- PostgreSQL:采用官方逻辑复制 test_decoding
这些捕获的增量数据,同样会由弹性伸缩模块根据新规则写入到新数据节点中。当增量数据基本同步完成时(由于业务系统未停止,增量数据是不断的),则进入规则切换阶段。
规则切换阶段
在此阶段,可能存在一定时间的业务只读窗口期,通过设置数据库只读或ShardingSphere的熔断机制,让旧数据节点中的数据短暂静态,确保增量同步已完全完成。
这个窗口期时间短则数秒,长则数分钟,取决于数据量和用户是否需要对数据进行强校验。 确认完成后,Apache ShardingSphere 可通过配置中心修改配置,将业务导向新规则的集群,弹性伸缩完成。