used_memory超过maxmemory会立即触发键淘汰，具体行为由maxmemory-policy决定；需同步监控used_memory_rss与mem_fragmentation_ratio（正常1.0–1.5），超1.5表明严重内存碎片，低于1.0则可能被系统swap；evicted_keys非零增长预示缓存穿透风险，须结合命中率、延迟、OPS及blocked_clients等指标交叉分析根因。
used_memory 超过 maxmemory 设置时，Redis 会开始淘汰数据——这不是“可能”，而是立刻触发，且淘汰行为取决于 maxmemory-policy 配置。一旦发生驱逐，业务侧就可能出现缓存穿透或响应抖动，所以这个指标必须实时盯紧。
内存使用与碎片率：两个数字决定是否要重启
只看 used_memory 不够，必须同步比对 used_memory_rss 和计算 mem_fragmentation_ratio：
-
mem_fragmentation_ratio = used_memory_rss / used_memory，正常范围是 1.0–1.5 - 大于
1.5表示内存碎片严重，redis-cli info memory里看到的used_memory_human和used_memory_rss_human差值过大（比如前者 2G，后者 5G），说明 malloc 分配器已无法有效复用空闲页 - 小于
1.0意味着 Redis 进程被系统 swap 到磁盘，延迟会陡增，top里能看到高si/so值 - 碎片率持续 >1.5 时，
activedefrag在 Redis 4.0+ 可启用，但效果有限；生产环境更推荐滚动重启（配合集群 failover）
命中率与驱逐数：缓存是否真在“干活”
缓存价值体现在 keyspace_hits 和 keyspace_misses 的比例上，但光算 hit_rate 容易误判：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 命中率突然下跌，先查
evicted_keys是否非零增长——如果是，说明内存不足导致键被踢出，不是业务缓存策略问题，而是资源配置问题 -
expired_keys短时间突增，可能意味着大量 key 设置了相同 TTL（如整点批量刷新），引发瞬时淘汰风暴，建议错峰设置过期时间 - 命中率长期低于
80%，再检查keys *类命令是否被高频调用（slowlog get可确认），这类命令会阻塞主线程并拖垮整体 OPS
延迟与 OPS：单线程模型下的真实压力信号
Redis 是单线程处理命令，instantaneous_ops_per_sec 高不代表健康，得结合 latency 看：
- 用
redis-cli --latency测基线延迟（注意避开后台 RDB/AOF 写入时段），若 P99 > 2ms 就需警惕 -
redis-cli --intrinsic-latency 100可排除网络干扰，测纯服务端处理能力；结果 >50ms 通常指向 CPU 或内存带宽瓶颈 -
instantaneous_ops_per_sec突然归零或剧烈抖动，大概率是慢查询（如HGETALL大 Hash）或阻塞命令（BLPOP）卡住主线程，此时blocked_clients也会同步上涨
连接与拒绝数：别让客户端拖垮实例
connected_clients 和 rejected_connections 是资源水位的前置指标：
-
maxclients默认 10000，但实际能支撑的连接数受系统ulimit -n限制；若rejected_connections非零增长，说明客户端未正确复用连接或连接池泄漏 -
blocked_clients> 0 且长期不降，要查是否有消费者没及时消费 list、stream，或timeout参数设得过大 - 连接数持续 >80%
maxclients，即使没拒绝，也会加剧文件描述符竞争和上下文切换开销，建议提前扩容或优化客户端连接管理
真正难监控的不是单个指标，而是指标之间的耦合关系——比如 evicted_keys 上涨时 used_memory 却没变，大概率是用了 volatile-lru 策略但所有 key 都没设 TTL；又比如 mem_fragmentation_ratio 正常但 latency 居高不下，可能是 CPU 被其他进程抢占。这些交叉线索，才是定位根因的关键。
