Redis发布订阅内存碎片清理方法

Redis的发布订阅（Pub/Sub）机制本身不会直接产生内存碎片，但未及时清理的订阅连接、消息积压或过大的客户端输出缓冲区（默认各1GB）会显著推高RSS内存占用，导致`mem_fragmentation_ratio`虚高，形成易被误判的“假性碎片”；而真实内存碎片主要源于键值对的频繁增删改，且Pub/Sub缓冲区内存不受Redis自动碎片整理（active-defrag）影响。因此，解决高碎片比的关键在于主动管控Pub/Sub连接生命周期——合理设置`client-output-buffer-limit pubsub`、定期清理空闲连接、分层监控`used_memory_rss`与缓冲区使用情况，而非盲目重启或执行`MEMORY PURGE`，否则可能引发客户端重连雪崩。

Redis 发布订阅（Pub/Sub）本身不直接产生内存碎片，但长期运行的订阅客户端断连未清理、消息积压或缓冲区配置不当，会间接加剧内存碎片问题。

Pub/Sub 的内存占用模式与碎片无关但影响 RSS

发布订阅不存储消息——它只在内存中暂存待投递的消息，一旦客户端断开或未及时读取，消息就丢弃。所以 PUBSUB 相关命令不会像键值对那样触发 jemalloc 的多次分配/释放循环，也不会留下内部碎片。

但它会影响 used_memory_rss：每个活跃订阅连接都持有输入/输出缓冲区，默认上限各 1GB（可通过 client-output-buffer-limit pubsub 调整）。如果大量客户端长期空闲或消费慢，这些缓冲区会持续驻留，推高 RSS，从而拉高 mem_fragmentation_ratio 的分母，掩盖真实碎片率。

• 缓冲区是预分配的连续内存块，不是小对象反复申请释放，所以不制造「外部碎片」
• 但大块缓冲区长期占着 RSS，会让 mem_fragmentation_ratio = used_memory_rss / used_memory 偏高，误判为碎片严重
• 尤其当 used_memory 很小（比如只有几百 MB），而多个 Pub/Sub 连接把 used_memory_rss 拉到几个 GB，比值可能 >2.0，但实际不是 jemalloc 碎片，而是“假性碎片”

如何区分 Pub/Sub 缓冲区膨胀和真实内存碎片

先确认是否真有碎片，而不是被缓冲区干扰：

• 执行 redis-cli info memory | grep -E "(used_memory|used_memory_rss|mem_fragmentation_ratio)"
• 再查当前 Pub/Sub 连接数：redis-cli client list type pubsub | wc -l
• 检查输出缓冲区使用情况：redis-cli client list | grep "omem="，看是否有连接的 omem 值异常高（比如 >50MB）
• 对比 MEMORY STATS 中的 "total.allocated" 和 "fragmentation" 字段，若 fragmentation 接近 1.0 但 mem_fragmentation_ratio 却 >1.8，大概率是 RSS 被缓冲区撑大了

真实碎片主要来自键值对的增删改，尤其是频繁 SET/HSET 大小波动的数据；Pub/Sub 只是“背锅侠”，得靠数据拆解定位。

自动碎片整理（active-defrag）在 Pub/Sub 场景下的行为限制

Redis 4.0+ 的自动碎片整理机制（active-defrag）默认对 Pub/Sub 连接的缓冲区内存无效——jemalloc 不会对这些缓冲区做合并或归还，因为它们是通过 mmap 或 malloc 直接申请的大块内存，且 Redis 不认为它们属于“可整理对象”。

• active-defrag-ignore-bytes 和 active-defrag-threshold-lower 只作用于键值对释放后留在 jemalloc arena 中的空闲页，不包括客户端缓冲区
• 即使开启 activedefrag yes，你也看不到 INFO memory 中 mem_fragmentation_ratio 因 Pub/Sub 缓冲区而下降
• 真正有效的手段是：控制连接生命周期（用完即退订）、设置合理的 client-output-buffer-limit pubsub（例如 32mb 8mb 60），或定期 CLIENT KILL TYPE pubsub 清理死连接

持续监测与触发清理的实操建议

别只盯 mem_fragmentation_ratio —— 它是结果指标，不是根因信号。你应该分层监控：

• 基础层：每 5 分钟采集 used_memory、used_memory_rss、mem_fragmentation_ratio、connected_clients、pubsub_channels、pubsub_patterns
• 连接层：用 redis-cli client list 抽样检查 omem 和 cmd 字段，识别长期空闲的 subscribe 连接
• 触发条件要拆开写：
  → 若 mem_fragmentation_ratio > 1.5 且 used_memory_rss - used_memory > 512mb，才真正考虑碎片整理
  → 若 pubsub_clients > 100 且平均 omem > 10mb，优先 kill 异常连接，而不是调 MEMORY PURGE
• MEMORY PURGE 可尝试，但它只对 jemalloc 的 retained pages 有效（即已释放但未归还 OS 的内存），对 Pub/Sub 缓冲区无效；且生产环境慎用，可能短暂阻塞主线程

最易被忽略的一点：很多团队把 mem_fragmentation_ratio 高直接等同于“该重启 Redis”，却没意识到，如果 Pub/Sub 客户端是长连接网关型应用（比如 WebSocket 后端），重启后所有客户端重连瞬间会打满输出缓冲区，反而引发雪崩。先控连接，再理内存，顺序不能反。

今天关于《Redis发布订阅内存碎片清理方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！