本文列举Redis集群、Redis开源版集群版扩缩容方案的不足,并介绍Tair(企业版)集群版无感扩缩容方案。
Redis集群版通常会涉及到数据节点弹性扩缩容、分片间的数据迁移等需求,但业界常见的扩缩容方案仍存在一些问题,例如按Key迁移速度慢、不支持多Key命令、Lua脚本无法迁移、大Key迁移出现卡顿甚至引发高可用切换、迁移失败回滚复杂等。
Tair推出的新一代以Slot复制为原理的无感迁移数据架构,优化实例内部线程调度算法,高效、准确地控制集群行为,支持真正的无感扩缩容。下文详细介绍了Redis集群、Redis开源版集群扩缩容方案的不足以及Tair(企业版)集群版无感扩缩容方案。
Redis集群常见扩缩容方案与不足
Redis集群弹性扩缩容
Redis集群通过Gossip协议传递数据,以槽(Slot)为数据的最小集合,并以遍历(并迁移)Key的方式迁移单个Slot。但该方案存在如下问题:
稳定性较差
数据按Key迁移,可能会导致同一Slot内涉及多Key的命令在迁移过程中执行失败。
无法同时拷贝Lua脚本,导致迁移后Lua脚本丢失。
数据拷贝方式可能会导致大Key迁移出现卡顿,甚至错误,触发高可用(HA)故障切换。
运维难度大
若迁移期间出现失败,需要依靠人工手动恢复数据库,难度高、耗时长且易出错。
按Key迁移通常速度慢,扩缩容所需耗时长,往往迫使业务方在业务低峰期进行扩缩容,甚至影响到业务正常进行。
基于数据同步迁移组件进行扩缩容
该方案不依靠Redis集群特性进行迁移,而是引入一个中间组件作为数据迁移工具。例如先构建一个新的集群实例,然后通过中间组件进行数据迁移,完成迁移后通过LoadBalancer组件切换访问路径,最终完成扩缩容操作。该方案存在如下问题:
全量数据同步耗时过长。
扩缩容期间需要同时拥有2套集群资源,成本较高。
LoadBalancer组件在切换过程中会不可避免地引发客户端连接断开的问题,同时切换生效时间较长,可能会导致长达10秒以上的服务不可用。
Redis开源版集群版平滑扩缩容方案与不足
Redis开源版集群版提供了平滑扩缩容解决方案,较好地解决了上述Redis集群版扩缩容存在的部分问题,但该方案也存在如下问题:
扩缩容变配期间的数据迁移过程有感知,可能存在秒级别的只读时间。
说明扩缩容涉及到数据迁移,通常过程为:服务端处理增量同步数据至差值小于一个阈值时,进入只读状态,等待剩余增量数据迁移完成,然后重定向客户端请求到新的地址。若服务端在只读状态期间收到更新请求,则会拒绝请求并返回只读错误,这类错误响应无法被业务逻辑平滑处理,从而影响到业务体验。
扩缩容变配的数据迁移任务与正常业务争抢处理资源,迫使用户需要在业务低峰期进行扩缩容操作,影响扩缩容的灵活性。
Tair(企业版)集群版无感扩缩容方案
Tair(企业版)集群版基于新一代管控架构,通过中心化控制组件,高效、准确地控制集群行为,支持真正的无感扩缩容。
本方案具有如下特点:
真正的无感扩缩容
Tair集群版在扩缩容过程中可实现客户端无感知、不闪断、无只读状态,满足随时弹性资源伸缩需求。
平滑处理扩缩容的关键在于缩小数据迁移时服务端的只读区间,Tair集群版实例通过动态评估增量差值,将数据库内核的只读区间(时间)控制到毫秒级别,远小于百毫秒级别的TCP重传时间,因此服务端理论上可规避只读错误。服务端只读区间(禁写)时,涉及待迁移Key的写请求将缓存至服务端,等待数据迁移结束后,向客户端返回重定向信息。同时,集群管理系统与数据库内核联动,数据迁移完成后将第一时间更新集群信息。因此,可以实现在客户端完全无感知的情况下完成扩缩容操作。
扩缩容过程平滑
Tair集群版通过优化实例内部的线程调度算法,对迁移任务进行细粒度控制,从而最大化提升线程执行效率,线程执行效率可从原先的10%提升到80%(可配置),实现在不影响业务服务的情况下最大化提升数据迁移速度。同时,Tair集群版在迁移过程中可保障数据高可靠,支持按细粒度扩缩容,且无明显RT(Reaction Time)上涨,杜绝由RT抖动错误触发高可用切换的隐患。
运维高效简便
Tair集群版解决多项Redis集群扩缩容的问题。
后台预拷⻉:Tair集群版采用后台预拷⻉方式,数据拷⻉过程中不会影响线上业务,拷⻉完成前源端持有完整数据,规避大Key迁移卡顿等问题。
一键回滚:在扩缩容过程中若发生异常情况,支持一键回滚。
数据按槽(Slot)迁移:数据按Slot迁移,规避同一槽(Slot)内涉及多Key的命令在迁移过程中执行失败的问题。
支持同时拷贝Lua脚本:在迁移过程中会同时拷⻉Lua脚本,规避迁移后脚本丢失问题。
支持最大256分片水平扩缩容。
低成本
相比基于中间组件的方案,无需同时持有2套集群资源,具有较低的成本。