I
Editorial
Redis 内存上涨不一定是「业务数据真多了」：碎片率和个别大 key 都能把实例拖到换机。本帖整理观测、治理与上线窗口注意点，具体命令以你使用的 Redis 版本为准。
一、先分清：用量 vs 碎片
1. `INFO memory` 看 `used_memory`、`used_memory_rss`、`mem_fragmentation_ratio`。比率长期明显高于 1.5（且 RSS 远大于 used）要怀疑碎片；接近 1 但仍涨，多半是数据或大 key。
2. 容器/ cgroup 环境里 RSS 受限制影响，结合宿主机与 `maxmemory` 策略一起看，避免误判。
二、大 key 怎么找
1. 用 `redis-cli --bigkeys` 或在线扫描工具分批扫，避开高峰全量 KEYS。
2. 关注：超大 string、上百万成员的 hash/set/zset、超长 list。大 key 删除会阻塞，生产禁用无脑 DEL。
3. 业务侧预防：拆分 key、控制单 key 体积、过期与压缩、避免「一个 key 扛整站会话」。
三、碎片治理
1. Redis 4+ 可开启 `activedefrag`（按版本与负载评估）；观察 CPU 与延迟，不要在已经打满的实例上突然开激进参数。
2. 有些碎片来自分配器与工作负载形态，重启/切换到新实例仍是最干净的手段——但要有副本与切换预案。
3. 写多删多的队列型负载更容易碎，可评估工作负载是否适合该数据结构。
四、删除与扩容的安全动作
1. 大 key 删除用渐进式（如 UNLINK、分批 HSCAN+HDEL），并盯 blocked 与延迟指标。
2. `maxmemory-policy` 与业务预期一致：缓存可淘汰；会话/队列不能随便 allkeys-lru。
3. 扩容或迁移时同步检查：热 key、大 key、持久化与复制积压。
五、建议的日常看板
used/RSS/碎片率、逐出次数、命中率、P99 延迟、大 key 扫描报告（定期）。有告警再动治理，避免「没事重启」。
欢迎分享你们在集群模式下降大 key、开主动碎片整理时的延迟变化经验。
一、先分清：用量 vs 碎片
1. `INFO memory` 看 `used_memory`、`used_memory_rss`、`mem_fragmentation_ratio`。比率长期明显高于 1.5（且 RSS 远大于 used）要怀疑碎片；接近 1 但仍涨，多半是数据或大 key。
2. 容器/ cgroup 环境里 RSS 受限制影响，结合宿主机与 `maxmemory` 策略一起看，避免误判。
二、大 key 怎么找
1. 用 `redis-cli --bigkeys` 或在线扫描工具分批扫，避开高峰全量 KEYS。
2. 关注：超大 string、上百万成员的 hash/set/zset、超长 list。大 key 删除会阻塞，生产禁用无脑 DEL。
3. 业务侧预防：拆分 key、控制单 key 体积、过期与压缩、避免「一个 key 扛整站会话」。
三、碎片治理
1. Redis 4+ 可开启 `activedefrag`（按版本与负载评估）；观察 CPU 与延迟，不要在已经打满的实例上突然开激进参数。
2. 有些碎片来自分配器与工作负载形态，重启/切换到新实例仍是最干净的手段——但要有副本与切换预案。
3. 写多删多的队列型负载更容易碎，可评估工作负载是否适合该数据结构。
四、删除与扩容的安全动作
1. 大 key 删除用渐进式（如 UNLINK、分批 HSCAN+HDEL），并盯 blocked 与延迟指标。
2. `maxmemory-policy` 与业务预期一致：缓存可淘汰；会话/队列不能随便 allkeys-lru。
3. 扩容或迁移时同步检查：热 key、大 key、持久化与复制积压。
五、建议的日常看板
used/RSS/碎片率、逐出次数、命中率、P99 延迟、大 key 扫描报告（定期）。有告警再动治理，避免「没事重启」。
欢迎分享你们在集群模式下降大 key、开主动碎片整理时的延迟变化经验。