Redis集群扩容与性能监控技巧

Redis集群扩容时CPU飙升往往并非单纯由数据迁移引起，更多源于客户端重试风暴、连接层压力或监控工具误用等隐性因素；本文直击实战痛点，教你通过INFO CPU与cluster指标组合分析快速区分迁移负载与客户端异常，借助抓包、日志和轻量轮询精准定位根因，并揭示迁移中TRYAGAIN锁键、重定向链路延迟、槽位状态盲区等易被忽视的关键风险点，同时提供迁移期间禁用高开销检查、优化重试策略、设置多维预警指标等即用型最佳实践。

Redis集群扩容时CPU飙升，怎么快速定位是迁移还是客户端打爆的？

Redis集群扩容期间CPU冲高，不能默认归咎于数据迁移。实际中更常见的是客户端重试风暴或连接复用失效导致的请求堆积。先确认 INFO CPU 里的 used_cpu_sys 和 used_cpu_user 是否同步飙升——如果只有 used_cpu_sys 显著升高，大概率是网络/连接层压力（比如大量短连接重建）；如果两者都涨，再查 INFO cluster 中 migrating_slots 和 importing_slots 是否非零。

• 查看迁移活跃度：redis-cli -c -h node1 -p 6379 cluster nodes | grep -E "(migrating|importing)"
• 抓包验证请求来源：tcpdump -i lo port 6379 -w redis-cpu.pcap，过滤出是否集中发往正在迁移的源节点
• 检查客户端日志里是否有密集的 MOVED 或 ASK 重定向响应，这是重试逻辑没兜住的典型信号

监控数据迁移进度时，redis-cli --cluster check 为什么反而拖慢迁移？

redis-cli --cluster check 默认会遍历所有槽位并执行 CLUSTER GETKEYSINSLOT 抽样，对每个槽发起多次 SCAN 请求。在迁移进行中，这会和 MIGRATE 命令争抢单线程资源，尤其当目标节点负载已高时，直接抬高 used_cpu_sys 并阻塞迁移队列。

• 迁移期间禁用自动 check，改用轻量轮询：redis-cli -h src -p 6379 cluster countkeysinslot {slot} 2>/dev/null 配合 redis-cli -h dst -p 6379 dbsize 对比增量
• 如果必须用 --cluster check，加 --verbose 并限制抽样数：--cluster check --verbose --slots 100
• 注意：该命令在 Redis 6.2+ 才支持 --slots 参数，旧版本只能停机检查

客户端响应延迟突增，是重定向开销大，还是迁移锁住了键？

Redis集群里 MOVED 重定向本身不耗时（纯文本响应），真正延迟来自客户端处理重定向后的二次请求链路。但若出现某几个键持续超时，大概率是这些键正被 MIGRATE 锁定——迁移过程中，源节点对正在迁移的键会短暂拒绝写入（返回 TRYAGAIN），客户端若没正确处理该错误，就会卡住或无限重试。

• 客户端必须识别 TRYAGAIN 并主动 sleep 后重试（推荐 50–100ms），而非当成普通失败立刻重发
• 避免在迁移窗口期执行 KEYS *、FLUSHDB 等全量操作，它们会触发 slot 锁等待
• 使用 redis-cli --cluster rebalance 时，加上 --threshold 1 可减少单次迁移槽数量，降低锁粒度

从监控指标看，哪些数值能提前预警迁移风险？

别等 CPU 到 90% 才反应。以下三个指标组合看，比单独看 CPU 更早暴露问题：

• instantaneous_ops_per_sec 在源节点持续低于目标节点 30% 以上，说明迁移吞吐跟不上写入节奏
• rejected_connections 在目标节点突然上升，代表 maxclients 或内存不足，迁移会卡在 WAIT 状态
• sync_full 在目标节点持续为 0，但 sync_partial_ok 频繁下降，说明主从复制缓冲区溢出，影响迁移稳定性

迁移不是“开始→结束”的原子过程，而是多个槽分批、异步推进的流水线。最容易被忽略的是：迁移中的槽，其读请求仍由源节点服务，但写请求可能被 TRYAGAIN 拦截——这个状态在监控里没有专用指标，只能靠 slowlog get 里频繁出现的 MIGRATE 调用和客户端错误日志交叉印证。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Redis集群扩容与性能监控技巧》文章吧，也可关注golang学习网公众号了解相关技术文章。