idistributedcache本身不防击穿，必须手动实现加锁→查缓存→查db→写两级的完整逻辑；单纯getstringasync+setstringasync因无互斥机制必然导致并发击穿。
直接说结论：IDistributedCache 本身不防击穿，它只是个接口；真正起作用的是你用它封装的逻辑——尤其是加锁、逻辑过期和二次检查这三步缺一不可。
为什么单纯调用 GetStringAsync + SetStringAsync 必然击穿
这是最常见也最危险的写法。缓存失效瞬间，多个请求同时走到 if (cachedData == null) 分支，全部触发 FetchDataFromDataSource，数据库立刻被压垮。
- 根本原因：没有互斥机制，
IDistributedCache的读写操作天然不带原子性保障 -
SetStringAsync不会自动帮你加锁，也不会重试，更不会判断“别人是不是已经在写了” - Redis 物理过期（
EXPIRE）会让 key 瞬间消失，放大击穿窗口
必须手动实现「获取锁 → 查 Redis → 再查 DB → 写两级」流程
不能依赖 IDistributedCache 自动兜底，得自己控制执行顺序。推荐用 StackExchange.Redis 原生客户端做锁，再用 IDistributedCache 做写入（保持抽象层）。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 锁 key 建议用
"lock:user:{id}"这类命名，避免和业务 key 冲突 - 用
redis.GetDatabase().StringSet(key, "1", TimeSpan.FromSeconds(3), When.NotExists)实现SETNX，超时设 3 秒防死锁 - 拿到锁后，**必须再次调用
GetStringAsync** ——防止其他线程已写完但你还没看到 - DB 查询成功后，先写 Redis（带逻辑过期字段），再写本地缓存（如用
IMemoryCache），不要反着来
逻辑过期值怎么塞进 IDistributedCache？
IDistributedCache 只认 byte[]，所以你要自己序列化含过期时间的结构体，而不是靠 AbsoluteExpirationRelativeToNow。
- 存的时候：把数据和
DateTimeOffset.UtcNow.AddMinutes(10)一起序列化成 JSON，再转byte[] - 取的时候：反序列化后先比对当前时间与
expireAt，过期才走锁重建逻辑 - 别用
DistributedCacheEntryOptions设物理 TTL —— 它和逻辑过期冲突，反而让 key 提前消失 - 示例结构：
{"data":{"id":123,"name":"xxx"},"expireAt":"2026-09-06T03:20:00Z"}
HybridCache 能省事，但不是银弹
如果你用的是 Microsoft.Extensions.Caching.Hybrid，它内置了 L1+L2 和基础锁逻辑，但默认不启用防击穿，且不支持逻辑过期语义。
- 必须显式配置
options.LockTimeout = TimeSpan.FromSeconds(2)和options.RefreshOnHit = true - 它的
GetOrCreateAsync在锁失败时默认返回 null，你需要包装一层 fallback 行为 - 仍需自己处理逻辑过期：从
IDistributedCache读出的值，得在 HybridCache 回源前做时间判断 - 多实例部署时，
LockProvider必须用 Redis 实现，不能用内存版，否则锁无效
真正难的不是写几行锁代码，而是所有环节都得对齐：本地缓存的 TTL 要比逻辑过期长、Redis 不设物理过期、锁超时必须短于业务查询耗时、回源后必须按顺序写入——漏掉任意一环，击穿就会在某个节点上复现。
