Redis Hash扩容时会发生什么性能波动？

Redis Hash扩容期间CPU和内存明显上涨，因渐进式迁移需持续哈希重计算、指针更新与内存拷贝，且ht[0]和ht[1]共存致内存短暂翻倍；负载因子超1触发扩容（BGS SAVE等场景放宽至5），目标大小为ht[0].used×2并向上取整为2的幂次方，易引发内存碎片与客户端延迟上升。

Redis Hash扩容期间CPU和内存会明显上涨

扩容不是瞬间完成的，而是渐进式迁移，但这个过程本身就会持续占用CPU做哈希重计算、指针更新和内存拷贝。同时，ht[0]和ht[1]两个哈希表共存，内存占用会短暂翻倍——哪怕只是临时的。

常见错误现象包括：INFO memory显示used_memory_peak_human突然跳升；redis-cli --stat观察到instantaneous_ops_per_sec波动剧烈；监控里看到rehashing指标非-1（即rehashidx >= 0）。

1. 负载因子超过1触发扩容，但若正在执行BGS SAVE或BGREWRITEAOF，阈值会放宽到5，此时更容易撞上高内存压力
2. 扩容目标大小是d->ht[0].used * 2，且必须是2的幂次方，所以实际分配可能比“刚好够用”更大
3. 内存碎片风险升高：新旧表内存不连续，释放ht[0]后未必能被OS立即回收，尤其在小内存机器上更敏感

客户端请求延迟变长，尤其是写操作

每次HSET、HDEL或HGET执行时，Redis都会顺带迁移一个桶（bucket）的数据。这意味着单次命令耗时变长，特别是当访问的是尚未迁移的旧表数据时，要查ht[0]和ht[1]两处——读写路径变复杂了。

使用场景中容易踩坑的是批量写入：比如用HMSET或管道（pipeline）塞入大量Hash字段，每个命令都触发一次迁移逻辑，叠加起来延迟明显。

1. 迁移粒度固定为“一个桶”，但桶内节点数不确定——如果某个桶链表很长（哈希冲突严重），单次迁移开销就大
2. rehashidx推进速度取决于操作频次，低流量时段可能拖很久才完成，导致性能波动持续时间不可控
3. 缩容（负载因子

并发连接数突增可能加剧rehash抖动

rehash本身不阻塞主线程，但所有客户端命令都要参与迁移任务。当并发请求数陡增（比如秒杀开场），单位时间内触发的迁移次数剧增，CPU争抢更激烈，used_cpu_sys和used_cpu_user会同步飙升。

这不是bug，是设计使然：Redis把rehash“摊”进日常操作，所以越忙越容易抖。你看到的延迟毛刺，往往不是网络或IO问题，而是rehash在后台悄悄干活。

1. 没有“暂停rehash”的安全开关，pauserehash字段仅用于持久化期间内部协调，不可手动干预
2. 监控关键指标应包含rehashing（是否正在进行）、ht0_used/ht1_used（两表实时数据量）、以及instantaneous_input_kbps（流量突增是否同步触发抖动）
3. 大Hash对象建议预估容量，用HCREATE类命令（如果客户端支持）提前分配空间，避免运行时频繁扩容

旧key长期不访问会导致rehash卡住

渐进式rehash依赖“有操作才迁移”。如果某个Hash里有大量key，但其中一部分长期无人访问（比如冷数据字段），那对应的桶就永远不会被迁移——rehashidx停在那里，ht[0]无法彻底释放，内存一直挂着。

这在配置类、日志类Hash中很常见：写一次，读零次，却始终占着双表内存。

1. 没有后台线程兜底迁移，全靠用户请求驱动，这是最易被忽略的设计约束
2. redis-cli --bigkeys只能发现大key，无法识别“半迁移”状态；需用DEBUG HTSTATS <key>（仅开发/测试环境）确认迁移进度
3. 真正解决办法不是等它自己动，而是主动触发访问——比如用HEXISTS轮询冷字段，或定期HGETALL强制推进，但要注意别引发新的性能雪崩