Redis String 类型无击穿防护能力，需应用层兜底；因其无状态、硬过期特性，热点 key 过期时并发请求会集体穿透至数据库，引发 miss 飙升与 DB 压力激增。
Redis String 类型本身不自带击穿防护能力，必须靠应用层策略兜底。单靠 SET / GET 无法解决热点 key 过期瞬间的并发穿透问题——这是由 String 的无状态、无锁、无逻辑过期机制决定的。
为什么 String 类型缓存击穿特别难防
String 是最“干净”的类型：它只存值，不带元信息。不像 Hash 或 Sorted Set 可以附带时间戳或版本号，String 的 EXPIRE 是硬过期，一到时间就彻底消失。一旦 user:10086 这类 key 到期，所有并发请求同时发现 GET 返回 null，就会集体涌向数据库。
- 现象明显：
redis.keyspace_misses瞬间飙升，redis.keyspace_hits断崖下跌 - 数据库慢查询里反复出现同一语句，但返回行数为 0
- Redis 监控里看到大量
GET+SET组合，且SET耗时波动剧烈
用互斥锁（Mutex）控制重建并发
这是最直接、上线成本最低的方案，核心是让只有一个线程去查库写缓存，其余线程等待后直接读新值。
- 锁 key 必须与业务 key 强绑定，例如
user:10086对应锁lock:user:10086 - 必须用
SET命令的NX EX参数组合，不能用SETNX单独加锁再EXPIRE—— 后者不是原子操作，可能锁成功但过期失败 - 锁超时时间要大于数据库查询+写缓存的最大耗时，否则可能多个线程同时拿到锁
- 别在重试逻辑里用递归调用，容易栈溢出；改用循环 + 退避（如
Thread.sleep(50)）
示例（Java + RedisTemplate）：
String lockKey = "lock:" + cacheKey;
Boolean isLocked = stringRedisTemplate.opsForValue()
.setIfAbsent(lockKey, "1", Duration.ofSeconds(10));
if (Boolean.TRUE.equals(isLocked)) {
try {
User user = userMapper.selectById(id);
if (user != null) {
stringRedisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(user), Duration.ofMinutes(30));
}
// 注意：空值也要写入，否则下次仍会抢锁
} finally {
stringRedisTemplate.delete(lockKey);
}
} else {
// 等待后重试，不要立即返回 null
Thread.sleep(50);
return getUserFromCache(id);
}
用逻辑过期替代物理过期
把过期判断从 Redis 移到应用层：缓存值本身包含数据 + 逻辑过期时间戳，GET 后解析再判断是否该更新，而不是等 Redis 自动删 key。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- value 必须是结构化格式（如 JSON），不能存裸字符串，否则无法附带时间戳
- 过期检查和异步刷新必须分离：检查发现逻辑过期，立刻返回旧值，另起线程刷新
- 刷新失败不能影响主流程，需有重试或告警，但绝不阻塞用户请求
- 注意并发刷新：多个线程同时发现逻辑过期，要避免重复刷库，可用
SETNX做轻量级刷新锁
示例 value 结构：{"data":{...},"expireAt":1720840320000}，应用读取后对比当前时间戳决定是否触发刷新。
别忽略本地缓存这一层
String 类型击穿压力最先打在 Redis 连接池和网络上，而本地缓存（如 Caffeine）能直接拦截大部分重复请求，大幅降低 Redis 层并发。
- 本地缓存 TTL 应比 Redis TTL 短（比如 Redis 设 30 分钟，本地设 10 分钟），避免本地长期持有过期数据
- 本地缓存也得支持空值缓存，否则无效 key 会反复穿透到 Redis
- 不要把本地缓存当最终一致性保障，它只是缓冲器；更新数据库后，必须主动
invalidate本地缓存 - 本地缓存大小要设限（如
maximumSize(10000)），防止 OOM
真正容易被忽略的是：逻辑过期和互斥锁都依赖「写库成功后必须同步更新缓存」这一前提。如果业务代码里存在先删缓存、再更新 DB 的 Cache-Aside 模式，那上面所有防护都会失效——因为缓存已被删，击穿风险照旧。
