Redis 7.0中怎样处理主从同步中的大Key删除_利用内存分段释放技术

Redis 7.0无“内存分段释放”机制，实际依赖UNLINK异步删除+渐进式拆分（如HSCAN/HDEL分批处理）+配置调优（如增大repl-backlog-size、client-output-buffer-limit）三者协同，否则主从同步仍会阻塞或断连。

Redis 7.0 并没有“内存分段释放”这个内置机制，所谓“分段释放”是误传；真正可用的是 UNLINK + 渐进式拆分 + 配置调优三者组合，否则主从同步仍会断连或延迟飙升。

UNLINK 不等于分段，它只是把删除扔给后台线程

很多人以为 UNLINK 能“分段释放内存”，其实不是：UNLINK 只是把 key 的元数据（如 dictEntry、robj 指针）从数据库中摘除，并把实际内存释放任务交给 lazyfree-thread 异步执行。但对大 Key 来说，后台线程仍要一次性遍历所有元素、归还内存页——这过程本身不拆分，只是不卡主线程。

• String 类型大 value（如 50MB）：UNLINK 立即返回，后台线程释放整块内存，无压力
• Hash/List/Set/ZSet 类型（含数万 field 或 member）：后台线程仍需逐个释放每个子项，若元素极多（比如 200 万），仍可能压垮 lazyfree 线程、堆积未释放内存
• 主从同步不受影响？错。主节点执行 UNLINK 后，该操作仍以一条 DEL 命令形式写入 AOF 并同步到从节点——从节点收到后照样得执行一次同步删除，照样阻塞

主从同步中真正有效的拆分必须在主节点上渐进执行

要避免复制流被一个大 Key 卡死，唯一可靠方式是：在主节点上用游标命令分批读取 + 写入新结构 + 清理旧字段，让每一步都变成小命令进入复制流。

• 对大 Hash：HSCAN myhash 0 COUNT 50 拉出 50 个 field，HSET myhash:shard01 ... 写入新 key，再 HDEL myhash f1 f2 ... 删除这 50 个——每轮最多 50 个字段，不超网络包限制
• 对大 ZSet：ZSCAN myzset 0 COUNT 100 + ZADD myzset:part1 + ZREM myzset，注意 ZREM 支持批量删，但别一次删超 500 个，否则从节点同步时仍可能超时
• 必须在主节点执行：从节点只读，不能参与任何写逻辑；所有 HSET/HDEL 都走复制流，确保从节点状态最终一致
• 加 SLEEP 0.005（如用 redis-cli --eval 调 Lua）：防止连续高密度命令打满主节点 CPU 和复制缓冲区

关键配置必须提前调大，否则 UNLINK 也救不了

即使用了 UNLINK，如果主从复制缓冲区太小，一个大 Key 的同步仍会触发断连。这些配置必须在问题出现前就设好：

• client-output-buffer-limit slave 512mb 128mb 60：把默认的 256MB/64MB 提高一倍，防止单次 bulk reply 打穿
• repl-backlog-size 1024mb：增大复制积压缓冲区，避免从节点重连时因 offset 脱离而触发全量同步（全量=又来一遍大 Key）
• lazyfree-lazy-server-del yes：开启 rename、flushdb 等隐式删除的异步化，但注意——它不影响主从同步中的 DEL 命令行为
• 禁用 CONFIG SET 动态改 maxmemory-policy：该命令会阻塞主线程，且切换瞬间可能批量淘汰，引发二次带宽洪峰

删除后内存不降？不是没释放，是没还给 OS

执行完 UNLINK 或拆分清理后，INFO memory 中 used_memory_rss 可能长期不下降，这不是 bug：

• jemalloc 默认不立即归还空闲内存页给操作系统，而是缓存起来供后续分配复用
• 确认是否真释放：看 used_memory（Redis 逻辑内存）是否下降，而非 rss
• 强制归还：仅限低峰期手动执行 MEMORY PURGE，但不要依赖它做日常治理
• 真正要盯的是 mem_fragmentation_ratio：持续 > 1.5 说明碎片严重，大 Key 拆分后建议重启实例（滚动重启）来彻底整理内存