ES与Redis联动时，缓存击穿和穿透需三节点协同防御：ES查询前拦截（布隆过滤器/参数校验）、Redis分层缓存、DB回源加锁；单点防护无效，且ES不当作缓存会放大击穿风险。
直接说结论：Elasticsearch 和 Redis 联动时，缓存击穿 和 缓存穿透 不能靠单边解决，必须在查询链路的三个关键节点做协同防御——ES 查询前拦截、Redis 缓存策略分层、数据库回源加锁。只依赖其中一环，问题照旧。
为什么 ES + Redis 联动反而放大击穿风险？
很多人把 ES 当“高级缓存”用，比如先查 redis.get("search:keyword:java")，没命中就走 es.search()，再写回 Redis。这埋了两个坑：
- ES 查询本身有延迟（尤其带聚合、高亮、深度分页），一旦 Redis 中某个搜索关键词 key 过期，瞬间大量请求会并发打到 ES，而 ES 不是为高并发简单查询设计的，容易触发线程池满、熔断或 OOM
- 用户搜 “abc123” 这种明显非法词，Redis 没缓存，ES 也查不到，但攻击者批量刷这类词，就会形成典型的
缓存穿透—— 请求既穿 Redis 又穿 ES，最后全压到后端业务 DB（比如用 ES 结果去查商品详情）
ES 查询前必须加布隆过滤器或参数校验
ES 不适合做存在性判断，所以不能等它返回空才决定是否放行。真实生产中，得在进 ES 之前就拦住无效请求：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 对高频搜索字段（如商品类目 ID、SKU 前缀、用户 UID）构建
BloomFilter，加载到应用内存或用RedisBloom模块。例如用户搜"category:999999"，先查布隆过滤器：bloom.exists("category_filter", "999999")，返回false就直接 400，不碰 ES - 对文本类搜索（如标题关键词），用正则或长度限制做前置过滤：
if (keyword.length() ，直接拒绝控制字符、超短词、纯数字串等低价值请求 - 避免把 ES 当兜底：不要写
if (redis == null) { esResult = es.search(...); if (esResult.isEmpty()) db.fallback(...) }，这种链式穿透一旦被刷，DB 和 ES 一起崩
Redis 缓存层必须区分“结果缓存”和“空值缓存”
同一个 search:keyword:java key，不能只存一种 value。你得拆成两层语义：
- 正常结果缓存：
redis.set("search:res:java", json, 300, TimeUnit.SECONDS)，TTL 设短（3–5 分钟），配合随机偏移防雪崩 - 空结果缓存：
redis.set("search:null:java", "1", 60, TimeUnit.SECONDS)，key 单独命名，TTL 更短（≤ 60 秒），且值只是占位符（不是null字符串，避免和业务真实null混淆） - 读取时严格双检：
String res = redis.get("search:res:java"); if (res != null) return parse(res); if (redis.exists("search:null:java")) return Collections.emptyList(); // 真的去查 ES
击穿场景下，ES 回源必须用逻辑过期 + 分布式锁
热点搜索词（如“iPhone16”）的缓存失效瞬间，并发请求不能都去调 RestHighLevelClient.search()。推荐用“逻辑过期”模式，不依赖 Redis 的物理 TTL：
- 存入 Redis 的不是原始 JSON，而是包装对象：
{"data": [...], "expireTime": 1725524340000} - 读取时先解析
expireTime，若已过期，再用redis.set("lock:search:iphone16", "1", "NX", "PX", 30000)尝试争锁 - 抢到锁的线程异步刷新 ES 并更新 Redis；没抢到的线程直接返回旧数据（即使逻辑过期，也比空转好），避免全部阻塞
- 注意：ES 刷新失败不能让锁永久持有，
PX 30000必须设，且业务代码里要确保 finally 中释放锁（或用 Lua 脚本原子删除）
最易被忽略的一点：ES 返回结果的“空”不等于业务意义上的“无数据”。比如搜“北京朝阳区”，ES 可能返回 0 条，但这是合法地理查询；而搜“北京朝***区”，ES 也返回 0 条，却是非法输入。这两者必须用不同机制拦截——前者该进缓存，后者该被布隆过滤器或正则挡在最外层。
