首先来聊聊缓存穿透——当用户请求的数据在Redis和数据库中均不存在时，每次请求都会直接穿透至数据库，导致数据库压力瞬间飙升。造成这一问题的常见原因包括非法参数、恶意攻击以及业务校验不完善。常规解决方案大家耳熟能详：参数校验、缓存空值、布隆过滤器。但真正棘手的是：当你发现线上服务突然变慢、数据库负载急剧升高、大量请求绕过Redis直接冲击后端，而本该存在于Redis中的缓存键却查不到——这并非单纯的“过期”，而是由缓存被清空、穿透、击穿或配置异常引发的缓存失效。接下来，我们用最直白的问题链倒推根因：无需依赖监控平台，不写一行代码，仅靠三次精准提问加一次验证动作，就能定位90%的Redis缓存失效问题。

第一步：确认缓存是否真的丢失

打开redis-cli，连接对应实例，执行exists your_cache_key（例如exists token:abc123）。若返回0，说明键确实不存在；若返回1，但get your_cache_key返回空字符串或null，表示缓存了空值，并非真正丢失。

注意：不要只检查一个key——建议挑选3～5个近期高频访问的key进行批量验证，避免因单个key过期而误判为全局失效。

第二步：查明“谁动了我的数据”

在redis-cli中执行monitor命令，保持窗口开启，等待10～15秒，观察是否有flushall、flushdb、del等批量操作出现。一旦发现此类命令，立即按Ctrl+C中断，然后执行info clients查看client list中的IP和端口，结合应用日志定位发起方。

【关键陷阱】在容器化部署场景下，monitor输出可能被重定向到日志文件，更可靠的方式是在宿主机上执行tail -f /data/logs/redis/monitor.log。

如果未发现清除命令，请转查info stats中的evicted_keys和expired_keys数值。若evicted_keys持续增长，说明内存不足触发了淘汰策略；若expired_keys突增，则表明确实发生了集中过期。

第三步：检查缓存本该存活多久

方法一：查看key的剩余生存时间
执行ttl your_cache_key。若返回-2，表示key不存在；返回-1，表示key永不过期；返回正数，才是真实的剩余秒数。对一批key批量执行ttl，观察是否集中在某几分钟内归零——这是缓存雪崩的前兆。

方法二：翻阅代码查找过期逻辑
搜索项目中所有setex、expire、@Cacheable(expire = ...)调用点。重点检查是否使用了固定值（如3600），而非带随机偏移的3600 + new Random().nextInt(600)。

方法三：检查配置文件是否被覆盖
进入Redis服务器执行config get maxmemory和config get maxmemory-policy。如果maxmemory设置过小（例如512MB），且maxmemory-policy为noeviction，则会导致写入失败而非淘汰——此时set命令会返回错误，缓存根本未存入。

第四步：验证“缓存是否被绕过了”

第一步：模拟穿透请求
使用curl发送一个明显不存在的key请求，例如curl "http://api.example.com/order?id=9999999999"，同时在Redis中监控incr miss_count_order_9999999999是否被创建。若未创建，说明空值缓存逻辑根本没有执行。

第二步：抓包观察实际数据流向
在应用服务器上执行tcpdump -i lo port 6379 -w redis.pcap，复现一次请求，然后用Wireshark打开pcap文件，过滤redis协议，确认请求是否确实发送到了Redis端口——许多“缓存失效”案例的根源其实是DNS解析失败、连接池耗尽或客户端配置指向了错误实例。

第三步：检查Shiro/Spring Security拦截器
如果你使用Shiro集成Redis作为session存储，请检查SecurityManager配置中的cacheManager是否被替换成了ConcurrentMapCacheManager——这种内存缓存会与Redis完全脱钩，所有缓存操作都在JVM内部完成，Redis中自然空空如也。