缓存穿透是指请求查询的数据在redis和数据库中均不存在，导致所有请求直接打到数据库，造成数据库压力过载；其成因包括非法参数、恶意攻击及业务校验缺失，解决方案有参数校验、缓存空值和布隆过滤器。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你发现线上服务突然变慢、数据库压力飙升、大量请求直接打到后端，而Redis里本该存在的缓存键却查不到——这不是“过期了”，而是缓存被清空、穿透、击穿或配置异常导致的失效。问小白不是工具名，是用最直白的问题链倒推根因：它不依赖监控平台，不写一行代码，只靠三次精准提问+一次验证动作就能定位90%的缓存失效问题。
第一步：确认是不是真丢了
打开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突增，才是真正的集中过期。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
第三步：问“它本来该活多久”
方法一：查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里自然空空如也。
