一眼看出redis内存是否快撑不住，需运行redis-cli info memory重点观察used_memory接近maxmemory、mem_fragmentation_ratio超1.5、used_memory_rss显著高于used_memory三指标，并结合趋势监控与淘汰策略有效性验证。
怎么一眼看出Redis内存是否快撑不住了
直接运行 redis-cli info memory，重点盯住三行：used_memory（Redis自己说用了多少）、used_memory_rss（操作系统说它占了多少）、mem_fragmentation_ratio（碎片率）。只要 mem_fragmentation_ratio 超过 1.5，说明内存“松散”得厉害；used_memory 接近你设的 maxmemory 值（比如设了 2gb，现在用了 1.8gb），就得动手了。
别只看单次结果。用脚本每 30 秒跑一次，把 used_memory 和 mem_fragmentation_ratio 写进日志或推给 Prometheus，画成趋势图——内存不是突然爆的，是缓慢爬升后某次写入触发淘汰或 OOM 的。
config set maxmemory-policy 为什么有时不生效
执行 config set maxmemory-policy allkeys-lru 后没反应？先确认两件事：maxmemory 是否已设置（config get maxmemory 返回值不能是 0 或 -1）；当前策略是否被配置文件硬编码覆盖（比如 redis.conf 里写了 maxmemory-policy noeviction，重启后会覆盖命令行设置）。
- 如果
maxmemory是 0，Redis 在 64 位系统下默认不限制内存，淘汰策略自然不触发 -
volatile-lru类策略只对带 TTL 的 key 生效，如果你全用永久 key，它就等于摆设 - 某些云托管 Redis（如阿里云 Tair、腾讯云 CRS）可能禁用部分动态 config 命令，得走控制台或 API 修改
哪些淘汰策略容易踩坑
选错策略会导致缓存击穿或数据误删，不是所有场景都适合 allkeys-lru：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
noeviction（默认）在内存满时直接拒绝写入，适合强一致性要求、不允许丢数据的场景，但业务要能兜住(error) OOM command not allowed when used memory > 'maxmemory' -
volatile-ttl看似“智能”，但若大量 key TTL 设置相近（比如统一设 3600 秒），它会在同一时间集中淘汰，引发瞬时压力 -
allkeys-random和volatile-random完全无规律，命中率波动大，只适合临时缓冲、可丢失数据的场景 -
allkeys-lfu比 LRU 更稳，但统计频率需要额外内存开销，小内存实例慎用
调整后怎么验证策略真在干活
改完策略不能只信返回 OK，得看实际行为：
先用 redis-cli --scan --pattern "*" | head -n 1000 | xargs -I{} redis-cli ttl {} 粗略扫一遍 key 的 TTL 分布；再模拟压测：批量写入带 TTL 的 key，然后持续 incr 一个不带 TTL 的计数器，观察 info stats 中的 evicted_keys 计数是否上涨。如果一直为 0，说明没触发淘汰——要么内存还没满，要么策略匹配不到 key（比如用了 volatile-lru 却全是永久 key）。
真正关键的是 keyspace_hits 和 keyspace_misses 的变化。策略调对了，命中率不会断崖下跌；如果调完发现 miss 暴增、延迟升高，大概率是淘汰逻辑误伤了热 key，得立刻切回保守策略并查具体被删了哪些 key。
