Redis 集群服务在互联网公司被广泛使用，众所周知服务集群化可以突破单节点的能力瓶颈，带来规模、可用性、扩展性等多方面的收益。在实际使用 Redis 集群的过程中，发现在进行涉及集群数据迁移的水平扩缩容操作时，业务侧多次反馈 Redis 请求的时延升高问题，甚至发生过扩容操作导致集群节点下线的可用性故障，并进一步引发迁移流程中断、节点间数据脑裂等一系列严重影响，给运维同事带来极大困扰，严重影响线上服务的稳定。

2.1 原生迁移介绍

Redis 集群功能采用无中心架构设计，集群中各个节点都维护各自视角的集群拓扑并保存自有的分片数据，集群节点间通过 gossip 协议进行信息协调和变更通知。具体来说 Redis 集群数据管理上采用虚拟哈希槽分区机制，将数据的键通过哈希函数映射到 0~16383 整数槽内，此处的槽位在 Redis 集群设计中被称为 slot。这样实际上每一个节点只需要负责维护一部分 slot 所映射的键值数据，slot 就成为 Redis 集群管理数据的基本单位，集群扩缩容本质上就是 slot 信息和 slot 对应数据数据在节点之间的转移。Redis 集群水平扩展的能力就是基于 slot 维度进行实现，具体流程如下图所示。

2.2 迁移问题分析

（1）时延分析

根据上述原生 Redis 集群迁移操作步骤的了解，可以总结出原生迁移功能按照 key 粒度进行的，即不断扫描源节点上正在迁移的 slot 数据并发送数据给目的节点，这是集群数据迁移的核心逻辑。微观来说迁移单个 key 数据对于服务端来说包含以下操作：

上述操作中涉及多个耗费线程处理时长的操作，首先序列化数据是非常耗费 CPU 时间的操作，如果遇到待迁移 key 比较大线程占用时长也会随之恶化，这对于单工作线程的 Redis 服务来说是不可接受的，进一步地网络发送数据到目标节点时会同步等待结果返回，而迁移目的端又会在进行数据反序列化和入库操作后才会向源节点进行结果返回。需要注意的是在迁移期间会不断循环进行以上步骤的操作，而且这些步骤是在工作线程上连续处理的，期间无法对正常请求进行处理，所以此处就会导致服务响应时延持续突刺，这一点可以通过 slowlog 的监控数据得到验证，迁移期间会在 slowlog 抓取到大量的 migrate 和 restore 命令。

（2）ask-move 开销

正常情况下每个正在迁移的 slot 数据都会一段时间内存在数据分布在迁移的两端的情况，迁移期间该 slot 数据访问请求可以通过 ask-move 机制来保证数据一致性，但是不难看出这样的机制会导致单个请求网络访问次数出现成倍的增加，对客户端也存在一定的开销压力。另外，对于可能存在的用户采用 Lua 或者 Pipline 这种需要对单个 slot 内多 key 连续访问的场景，目前大部分集群智能客户端支持有限，可能会遇到迁移期间相关请求不能正常执行的报错。另外需要说明的是，由于 ask-move 机制的只在迁移两端的主节点上能触发，所以迁移期间从节点是不能保证数据请求结果一致性的，这对于采用读写分离方式访问集群数据的用户也非常不友好。

（3）拓扑变更开销

为了降低迁移期间数据 ask-move 的机制对请求的影响，正常情况下原生迁移每次只会操作一个 slot 迁移，这就导致对每一个迁移完成的 slot 都会触发集群内节点进行一次拓扑更新，而每次集群拓扑的更新都会触发正在执行指令的业务客户端几乎同时发送请求寻求更新集群拓扑，拓扑刷新请求结果计算开销高、结果集大，大大增加了节点的处理开销，也会造成正常服务请求时延的突刺，尤其对于连接数较大、集群节点多的集群，集中的拓扑刷新请求很容易造成节点计算资源紧张和网络拥塞，容易触发出各种服务异常告警。

（4）迁移无高可用

原生的迁移的 slot 标记状态只存在于迁移双端的主节点，其对应的从节点并不知道迁移状态，这也就导致一旦在迁移期间发生节点的 failover，迁移流程将会中断和出现 slot 状态残留，也将进一步导致迁移 slot 数据的访问请求无法正常触发 ask-move 机制而发生异常。例如迁移源节点异常，那么其 slave 节点 failover 上线，由于新主节点并不能同步到迁移状态信息，那么对于迁移中 slot 的请求就不能触发 ask 回复，如果是一个对已经迁移至目标节点的数据的写请求，新主节点会直接在本节点新增 key，导致数据出现脑裂，类似地如果处理的是已经迁移数据的读取请求也无法保证返回正确结果。

3.1 优化方向思考

通过原生数据迁移机制分析，可以发现由于迁移操作涉及大量的同步阻塞操作会长时间占用工作线程，以及频繁的拓扑刷新操作，会导致请求时延不断出现上升。那么是否可以考虑将阻塞工作线程的同步操作改造成为异步线程处理呢？这样改造有非常大的风险，因为原生迁移之所以能够保证迁移期间数据访问的正确性，正是这些同步接口进行了一致性保证，如果改为异步操作将需要引入并发控制，还要考虑迁移数据请求与 slave 节点的同步协调问题，此方案也无法解决拓扑变动开销问题。所以 vivo 自研 Redis 放弃了原生按照 key 粒度进行迁移的逻辑，结合线上真实扩容需求，采用了类似主从同步的数据迁移逻辑，将迁移目标节点伪装成迁移源节点的从节点，通过主从协议来转移数据。

3.2 功能实现原理

3.3 改造效果分析

（1）时延影响小

对于 slot 迁移操作而言，主要涉及迁移源和目的两端的开销，对于基于主从同步机制实现的新 slot 迁移，其源节点主要开销在于生成 RDB 和传送网络包，正常对于请求时延影响不大。但是因为目的节点需要对较大的 RDB 文件片段数据进行接收、加载，由于目的节点迁移时也需要对正常服务请求响应，此时不再能采用类似 slave 节点将所有数据收取完以后保存本地文件，然后进行阻塞式数据加载的方案，所以新 slot 迁移功能对迁移目的节点的数据加载流程进行了针对性改造，目的节点会按照接收到的网络包粒度将数据按照下图所示进行递进式加载，即 slot 迁移目标节点每接收完一个 RDB 数据网络包就会尝试加载，每次只加载本次网络包内包含的完整元素，这样复合类型数据就可以按照 field 粒度加载，从而降低多元素大 key 数据迁移对访问时延的剧烈影响。通过这样的设计保持原来单线程简洁架构的同时，有效地控制了时延影响，所有数据变更操作都保持在工作线程进行，不需要进行并发控制。通过以上改造，基本消除了迁移大 key 对迁移目的节点时延影响。

（2）数据访问稳定

新 slot 迁移操作期间，正在迁移的数据还是存储在源节点上没有变，请求继续在源节点上正常处理，用户侧的请求不会触发 ask-move 转发机制。这样用户就不需要担心读写分离会出现数据不一致现象，在进行事务、pipeline 等方式封装执行命令时也不会出现大量请求报错的问题。迁移动作一旦完成，残留在源端的已迁移 slot 数据将成为节点的残留数据，这部分数据不会再被访问，对上述残留数据的清理被设计在 serverCron 中逐步进行，这样每一次清理多少数据可以参数化控制，可以根据需要进行个性化设置，保证数据清理对正常服务请求影响完全可控。

（3）拓扑变更少

原生的迁移功能为了降低 ask-move 机制对正常服务请求的影响，每次仅会对一个 slot 进行数据迁移，迁移完了会立即发起拓扑变更通知来集群节点转换 slot 的属主，这就导致拓扑变化的次数随着迁移 slot 的数量增加而变多，客户端也会在每一次感知到拓扑变化后发送命令请求进行拓扑更新。更新拓扑信息的命令计算开销较大，如果多条查询拓扑的命令集中处理，就会导致节点资源的紧张。新的 slot 迁移按照节点进行数据同步，可以支持同时迁移源节点的多个 slot 甚至全部数据，最后可以通过一次拓扑变更转换多个 slot 的属主，大大降低了拓扑刷新的影响。

（4）支持高可用

集群的数据迁移是一个持续的过程，这个过程可能长达几个小时，期间服务可能发生各种异常情况。正常情况下的 Redis 集群具有 failover 机制，从节点可感知节点异常以代替旧主节点进行服务。新 slot 迁移功能为了应对这样的可用性问题，将 slot 迁移状态同步给从节点，这样迁移期间如果集群迁移节点发生 failover，其从节点就可以代替旧主节点继续推进数据迁移流程，保证了迁移流程的高可用能力，避免人工干预，大大简化运维操作复杂度。

通过对比以上原生和自研集群 slot 迁移期间的时延监控数据，可以看出自研 slot 迁移功能迁移数据期间迁移两端节点的请求响应时延表现非常平稳，也可以表现出经过主从复制原理改造的 Redis 集群 slot 迁移功能具备的优势和价值。

原生 Redis 集群的扩缩容功能按照 key 粒度进行数据转移，较大的 key 会造成工作线程的长时间占用，进而引起正常服务请求时延飙高问题，甚至导致节点长时间无法回复心跳包而被判定下线的情况，存在稳定性风险。通过同步机制改造实现的新 slot 迁移功能，能显著降低数据迁移对用户访问时延的影响，提升线上 Redis 集群稳定性和运维效率，同时新的 slot 迁移功能还存在一些问题，例如新的迁移造成节点频繁的 bgsave 压力，迁移期间节点内存占用增加等问题，未来我们将围绕这些具体问题，继续不断优化总结。