Redis 内存快满了，你会怎么确认是过期策略、淘汰策略还是业务 Key 设计的问题？
我的判断
Redis 内存接近上限时要先分清数据是否仍有 TTL、哪些 key 在增长、是否发生淘汰，再决定修业务还是调策略。
我会先看 used_memory、used_memory_rss、maxmemory、evicted_keys、过期数量和内存碎片率。used_memory 持续增长但 TTL key 比例下降，通常是业务忘设过期；RSS 远高于 used memory，可能是碎片或 fork/COW；淘汰突然增加则说明工作集已经超过容量。
再用 MEMORY USAGE、抽样扫描和 keyspace 统计找大 key 与增长最快前缀，避免线上直接全量 KEYS *。确认是无界集合、重复版本 key、value 过大还是过期时间写错。
策略根据数据语义选：纯缓存常用 allkeys-lfu/lru；不能丢的 key 不应和可淘汰缓存混在同一实例。noeviction 会让写入报错，适合必须显式失败的场景，但需要容量告警。
治理优先删无用数据、补 TTL、拆大 key、限制集合长度，再评估扩容。只把 maxmemory 调大，会把同一个增长问题推迟到下一次。