缓存穿透导致404/500，缓存雪崩引发504/503：穿透是单个非法key反复打库致慢查询或异常返回；雪崩是大量key集中失效或Redis宕机，引发DB过载、上游超时与熔断，造成系统级连锁故障。
会，但机制完全不同：缓存穿透通常引发 500 或 404，而缓存雪崩更可能造成大面积 504、503 甚至上游服务返回 timeout。这不是 Redis 自身返回的 HTTP 状态码，而是后端服务在异常链路中产生的响应结果。
缓存穿透导致 404 / 500 的典型路径
当请求一个数据库和缓存都不存在的 key（比如恶意构造的 user:9999999999），常见处理逻辑是：
- 查
redis.get("user:9999999999")→ 返回null - 查
db.queryUser(9999999999)→ 返回null或抛出异常（如NoResultException） - 若未做空值缓存或参数校验，每次请求都走完 DB 查询 + 异常捕获流程
- 高并发下 DB 连接池耗尽、SQL 执行超时、事务阻塞 → 触发服务层
500 - 若业务明确返回“资源不存在”，且没兜底逻辑，可能直接返回
404
关键点：穿透本身不改变 HTTP 状态码语义，但会让“本该快速失败”的请求变成“慢查询+异常堆栈”，最终由接口框架或网关按超时/异常策略决定返回码。
缓存雪崩引发 504 / 503 的真实原因
雪崩不是单个请求的问题，而是系统级连锁反应：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 大量 key 同时过期（如
product:*:stock全部设为EXPIRE 3600），导致瞬间所有请求回源 DB - 数据库 CPU、连接数、IO 达到瓶颈 → 查询延迟从 10ms 涨到 2s+
- 上游服务（如 Spring Boot 接口）配置了
feign.client.config.default.connectTimeout=1000→ 大量请求在 Feign 层超时，返回504 Gateway Timeout - 若网关（如 Nginx）设置了
proxy_read_timeout 3s，而下游服务因 DB 压力已无法在时限内响应 → 返回503 Service Unavailable - 部分服务启用了熔断（如 Sentinel/Hystrix），触发降级逻辑 → 可能统一返回
503或自定义错误体
注意：504 一定来自反向代理或 API 网关，503 可能来自网关，也可能来自应用自身主动返回（如健康检查失败时）。
为什么不能只看 Redis 是否响应正常？
Redis 在雪崩或穿透场景下往往完全正常——它只是“没数据”或“没被访问”，真正崩溃的是下游依赖：
-
redis.ping()仍返回PONG，但redis.get("hot_key")返回null（击穿/穿透）或根本没被调用（雪崩时请求全卡在 DB 层） - 监控里 Redis 的
connected_clients、used_memory看似平稳，但rejected_connections可能突增（说明客户端连不上，已是严重雪崩后期） - 数据库慢查询日志暴增、
Threads_running> 200、连接池active耗尽 —— 这些才是根因指标
线上排查时，如果发现大量 504 伴随 Redis 缓存命中率从 95% 直降到 30%，第一反应不该是重启 Redis，而是立刻检查 DB 负载和缓存 key 的 TTL 分布。
