模拟 Redis 挂了、数据刚好过期、100 个请求同时打进来，这套单元测试怎么搭
缓存层重构的关键在于用可控的 Mock Redis Client 精确模拟异常态，而非简单返回 null。通过接口化底层操作，可模拟缓存未命中、连接超时和数据过期三种场景，并利用并发原语发起 100 个请求，验证数据库仅穿透一次。测试需覆盖雪崩延迟、脏数据清理等边界情况，并集成到 CI 中，开启 race detector 以捕获竞态条件。
标签: #缓存穿透
共 6 篇文章
查缓存没命中就全砸到库上，连接池满了怎么办？我用 CompletableFuture 把重复请求合并了一下
请求合并是解决缓存穿透的高效方案：用 ConcurrentHashMap 存 CompletableFuture，首个线程执行查询，后续线程挂起等待同一结果，避免数据库连接池被重复查询打满。需注意用 Optional 包装空值、finally 清理 Map、设置容量上限防内存膨胀，配合本地缓存可消化缓存过期瞬间的并发流量。
缓存命中率跌到多少该告警？我们反过来用空值率和穿透量推了一把阈值
将告警指标从缓存命中率改为空值率和穿透量，可大幅提升异常捕捉速度。空值率直接反映“查无此数据”的请求占比，信号清晰且误报少；配合绝对穿透量阈值作为二级确认，能有效过滤低流量干扰。组合告警规则将发现延迟从分钟级降至秒级，并联动空值缓存策略实现自动止血，同时需注意集群聚合和内存保护等落地细节。
线上缓存雪崩了三次，我们靠自动识别热点 Key 和动态分散才把这事摁住
面对频繁的热点 Key 引发的缓存雪崩，团队构建了一套自动化解决方案。通过客户端采样与 Flink 基线偏离度算法，能在 20 余秒内自动识别热点。识别后，系统会动态计算副本数并分散读请求，同时利用 Keyspace 通知异步同步数据，保证最终一致性。此外，还加入了客户端限流、分片熔断和本地缓存三重兜底，实现了对业务透明的热点防护。
布隆过滤器防缓存穿透，位数组大小和哈希函数个数不是你拍脑袋定的
布隆过滤器的核心在于位数组大小和哈希函数个数的计算。从误判率公式出发，可根据预期数据量和可接受误判率反推位数组大小，再计算最优哈希函数数量。Guava和RedisBloom等工具可自动完成参数计算，自实现时需注意哈希函数选择与双哈希技巧。线上需预留余量并定期重建，以防数据增长导致误判率飙升。
在 Spring Boot 里把缓存穿透的三种方案压测了一遍，性能差距比想象中大
Spring Boot 防缓存穿透方案对比：布隆过滤器、空值缓存与互斥锁实现及压测。布隆过滤器吞吐量最高达8247 ops/s，延迟仅0.97ms，内存占用小；空值缓存实现简单但内存易膨胀；互斥锁性能最差，不适合穿透场景。组合方案可兼顾性能与零数据库压力。