Redis Pipeline 不能防止缓存穿透，反而可能加剧风险：它仅优化网络传输，不校验key合法性；批量请求不存在的key会集中触发大量数据库查询，放大穿透危害。
Redis Pipeline 本身不能防止缓存穿透，它甚至可能加剧穿透风险——如果你在 pipeline 中批量请求大量不存在的 key，数据库压力会集中爆发，而不是分散。
为什么 Pipeline 不解决穿透问题
Pipeline 是客户端把多个命令打包发给 Redis，减少网络往返，提升吞吐。但它不改变业务逻辑：如果这批命令里包含 GET user:9999999、GET user:9999998 这类根本不存在的 key，Redis 依然全部 miss，后端服务照常触发大批量数据库查询——而且是并发、集中、无缓冲地打过去。
- 缓存穿透本质是「请求合法性校验缺失 + 无效 key 未拦截」，Pipeline 只负责传输，不参与判断
- 它放大了单次请求的负载密度：100 个空 key 的 pipeline 请求 = 100 次 DB 查询在极短时间内抵达
- 某些 ORM 或 Redis 客户端在 pipeline 失败时重试策略不当，反而造成重复穿透
Pipeline 在穿透防护中能起什么作用？
它只在「已有防护措施的前提下」提升效率，不是防护手段本身。比如你已用布隆过滤器做前置拦截，Pipeline 可以安全地批量查已确认存在的 key：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 布隆过滤器判定
user:1001、user:1002、user:1003都大概率存在 → 才用 pipeline 批量GET - 空值缓存已启用，且 key 命中率高 → pipeline 查一批已知有缓存的 key，避免多次 round-trip 开销
- 注意：pipeline 内不能混用写操作（如
SET空值）和读操作，否则失败回滚逻辑复杂，易出错
实际编码中容易踩的坑
很多人误以为加 pipeline 就等于“优化了缓存层”，结果让穿透更隐蔽、更难监控：
- 日志里只看到一条 pipeline 请求，但背后触发了 50 次 DB 查询 —— 监控指标（如 Redis
miss数）没变，DBslow query却飙升 - 用
redisTemplate.executePipelined()时没检查返回 List 中每个元素是否为null，直接反序列化报NullPointerException，掩盖了穿透源头 - 在限流/熔断逻辑外使用 pipeline，导致突发流量绕过保护机制直达 DB
真正要防穿透，得在 pipeline 之前卡住非法 key：参数校验、布隆过滤器、ID 范围白名单、接口级风控。Pipeline 只是高速通道，不是安检门。
