redis内存泄漏最直接的表现是used_memory在业务稳定时持续单向上涨；需结合info memory定期监控、memory stats排查客户端缓冲区膨胀、keys扫描验证ttl合理性，并通过rdb快照对比识别隐式数据结构膨胀。
看 used_memory 是否持续单向上涨
内存泄漏最直接的表现不是“爆内存”，而是 used_memory 在业务数据量不变、无新功能上线、TTL 设置合理的情况下，仍呈现数小时至数天的**单调上升趋势**。用 redis-cli info memory 定期抓取（比如每10分钟），重点比对：used_memory、used_memory_peak、used_memory_rss。如果 used_memory 不断刷新峰值，而 dataset.bytes（来自 MEMORY STATS）几乎不动，基本可锁定是内部开销在涨。
查 clients.normal 和 replication.buffer 是否异常膨胀
很多“假泄漏”其实是客户端缓冲区积压：某个慢消费者没及时读取 pub/sub 消息，或从节点网络卡顿导致主节点堆积复制缓冲区。运行 MEMORY STATS，检查：clients.normal、clients.replica、replication.buffer 这几项是否远超日常基线（比如平时 2MB，突然涨到 200MB）。这类问题不会触发 key 过期或淘汰，但会让 total.allocated 持续走高，表现和泄漏一模一样。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
对比 keys.count 和实际业务生命周期
Redis 不会主动清理已过期但尚未被访问的 key（惰性删除 + 定期抽样），所以 keys.count 长期只增不减，尤其在高频写入临时 session、验证码类 key 的场景下。用 redis-cli --scan --pattern "*session*" | wc -l 快速估算可疑前缀数量，再结合业务逻辑判断：这些 key 理论上应该在 30 分钟后就消失，但扫描发现大量 TTL 为 -1 或剩余时间 >2 小时，说明代码漏设 EXPIRE 或用了 SET 而非 SETEX。
用 rdb -c memory 抓快照做横向对比
单次 INFO 是静态切片，看不出变化。真正要确认泄漏，得靠 RDB 快照对比：在凌晨低峰期 dump 一次 dump.rdb，12 小时后再 dump 一次，用 rdb -c memory 分别导出 CSV，按 size_in_bytes 排序，重点关注相同 key 名但 size 增长 >50% 的条目——这往往是 list/set 不断 LPUSH/SADD 却不 LTRIM/SPOP 导致的隐式膨胀，比键数量增长更危险。
mem_fragmentation_ratio 高可能是 jemalloc 分配器行为，used_memory_rss 大于 used_memory 也不一定代表泄漏——关键得把内存增长和业务动作、客户端行为、键生命周期三者对齐，否则容易在碎片率或缓冲区上浪费半天。
