Redis Cluster集群在扩容或者缩容（增加/减少节点）时，线上业务会受到什么影响？

知识点图片

Redis Cluster 官方设计是支持平滑、在线的扩容和缩容的，理论上不会导致业务停机（No Downtime）。

但是，“不停机”并不意味着“无感知”。在实际生产环境中，由于扩缩容的核心本质是槽位（Slot）和数据的迁移，线上业务不可避免地会受到一定程度的影响。

总体来说，影响主要集中在请求延迟增加、网络/CPU资源争抢以及特定场景下的报错。以下是具体的详细分析：

无论是扩容还是缩容，核心动作都是把一部分 Hash Slot（以及里面的所有 Key）从源节点迁移到目标节点。这个过程中：

ASK 重定向导致的网络开销：当客户端请求一个正在迁移的 Slot 中的 Key 时：
- 如果 Key 还在源节点，源节点直接处理。
- 如果 Key 已经迁移到目标节点，源节点会返回一个 ASK 错误（包含目标节点的 IP 和端口）。
- 客户端收到 ASK 后，需要先向目标节点发送 ASKING 命令，然后再发送真正的操作命令。
- 影响：原本 1 次网络往返（RTT）就能完成的请求，变成了 3 次（请求源节点 -> 发送 ASKING -> 发送实际命令）。这会导致部分请求的延迟直接翻倍甚至变高数倍。
CPU 争抢：数据打包、序列化、网络传输都需要消耗源节点和目标节点的 CPU。如果节点原本负载就很高（例如 CPU 使用率 > 60%），迁移会抢占主线程处理业务命令的 CPU 时间，导致整体响应变慢。

这是扩缩容时最大的风险点。

Redis 的 MIGRATE 命令是同步且阻塞的。在迁移某个具体的 Key 时，源节点的主线程会被阻塞，直到目标节点确认接收完毕。
如果遇到几十 MB 甚至上百 MB 的大 Key（如超大的 Hash、List、Set），迁移这一个 Key 可能需要几百毫秒甚至几秒。
影响：这期间源节点无法处理任何其他客户端请求。如果阻塞时间超过了 cluster-node-timeout，甚至会误触发集群的故障转移（主从切换），导致业务大面积报错。

数据迁移会在节点之间产生大量的内部网络流量。

客户端实现不标准：部分老旧或者实现不完善的 Redis 客户端（或自己手写的客户端）可能无法正确处理 ASK 和 MOVED 重定向。这会导致这部分客户端直接抛出异常，业务请求失败。
连接池耗尽或超时：由于部分请求延迟增加，如果客户端设置的超时时间（Timeout）非常短，可能会引发大面积超时（Timeout Exception）。超时会导致连接被长时间占用，进而可能导致客户端连接池被打满。

扩容（增加节点）：新节点是空的，压力主要在源节点（提供数据的一方）以及集群内部的网络带宽。影响相对可控。
缩容（下线节点）：要把下线节点的所有数据全部塞给集群内其他还在运行的节点。这不仅有网络传输压力，还会导致目标节点的内存突然增长。如果目标节点内存不足，可能会触发 OOM 杀进程或数据淘汰策略（Eviction），造成数据丢失。

为了保证业务平稳度过扩缩容时期，运维和开发团队通常需要做到以下几点：

避开业务高峰期操作
永远选择在夜间或业务低谷期（如凌晨 2:00 - 5:00）进行数据迁移。
提前清理和拆分大 Key（核心强制要求）
在迁移前，必须通过工具（如 redis-cli --bigkeys）扫描大 Key。如果有大 Key，必须先由业务方配合拆分或清理，绝对不能带着大 Key 做迁移。
控制迁移的速度
使用 redis-cli --cluster rebalance 等工具时，可以通过调整 pipeline 大小或增加迁移的停顿时间，降低迁移速度，用时间换取集群的稳定性。尽量避免一次性大批量迁移 Slot。
调整客户端参数配置
在扩缩容期间，可以适当调大客户端的超时时间（Timeout），防止因为短暂的 ASK 重定向或网络波动导致业务大面积抛错。
容量与内存评估（特别是缩容）
缩容前，严格计算剩余节点是否有足够的可用内存来承接被下线节点的数据，预留至少 20%-30% 的内存 buffer，防止触发 maxmemory 驱逐策略。
完善的监控与回滚预案
在执行过程中密切盯盘 Redis 的 CPU、内存、网络 IO 以及客户端报错日志（特别是 Timeout 和 Cluster Redirect 异常）。一旦发现业务报错率飙升，应立即暂停迁移脚本。

总结：
Redis Cluster 扩缩容对线上业务有影响，但通常不会中断服务。主要表现为延迟抖动和偶发超时。只要提前处理掉“大 Key”，控制好迁移速率，并在低谷期操作，业务层几乎是无感知的。

播面