缓存雪崩本质是大量key集中过期或Redis整体不可用导致请求穿透至数据库，必须由业务层在写入时手动添加随机过期时间，Redis集群不提供自动打散能力。
缓存雪崩不是“会不会发生”的问题，而是“什么时候发生、影响多大”的问题——只要大量 key 的 EXPIRE 时间高度集中，或 Redis 集群整体不可用，雪崩就可能在促销、重启、批量预热后几秒内爆发。
为什么随机过期时间必须在业务层手动加，不能靠Redis集群自动处理
Redis Cluster 只负责分片和故障转移，SET key value EX 3600 这样的命令会原样执行，不会自动叠加随机偏移。很多团队误以为“上了集群就天然防雪崩”，结果所有分片上的商品缓存都在凌晨 0:00 同时失效，数据库连接数瞬间打满。
- 随机逻辑必须写在 C# 代码里，比如调用
StringSetAsync前先算好最终 TTL - 基础过期时间（如 24 小时）要和随机范围（如 ±15 分钟）分开管理，避免硬编码混在一起
- 如果用了
StackExchange.Redis的IDatabase.StringSetAsync(string, RedisValue, TimeSpan?)，TimeSpan必须是计算后的最终值，不是“基础值 + new Random().Next(...)”这种每次调用都变的表达式（否则单元测试无法稳定复现）
如何用 StackExchange.Redis 实现带扰动的缓存写入
关键不是“加不加随机”，而是“随机得足够散、且不破坏业务语义”。比如商品详情缓存设为 24h ± 20min，比统一 24h 能把失效峰拉平成一个持续 40 分钟的缓坡。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 推荐封装一个辅助方法：
GetRandomizedTtl(TimeSpan baseTtl, TimeSpan maxOffset)，返回baseTtl.Add(TimeSpan.FromMinutes(new Random().NextDouble() * maxOffset.TotalMinutes * 2 - maxOffset.TotalMinutes)) - 不要对每个请求都新建
Random实例（高并发下种子重复导致随机性坍塌），改用Random.Shared（.NET 6+）或静态Random实例加锁 - 对于同一业务实体的多个缓存 key（如
product:123:detail、product:123:stock），建议共用同一个随机偏移量，避免内部数据状态不一致
示例片段：
var finalTtl = GetRandomizedTtl(TimeSpan.FromHours(24), TimeSpan.FromMinutes(20));
await db.StringSetAsync($"product:{id}:detail", json, finalTtl);当 Redis 不可用时，仅靠“重试+随机延迟”不够，必须有降级兜底
缓存雪崩最危险的场景不是“大量 key 过期”，而是“Redis 整体不可用”——此时所有 StringGetAsync 都抛 RedisConnectionException 或超时，若没做熔断，线程池会迅速耗尽。
- 不要只依赖
try/catch重试：重试 3 次 + 每次随机 sleep 50~200ms，只会把压力更均匀地砸向数据库 - 必须引入熔断器（如
Polly的CircuitBreaker），统计连续失败率，触发后直接跳过 Redis 调用，走降级逻辑（如返回默认值、查本地缓存、或直接报错） - 降级逻辑本身也要轻量：避免在降级路径里再查一次数据库或调远程服务，否则只是把雪崩从 Redis 转移到了另一层
真正容易被忽略的点：随机偏移量不能太小（如 ±30 秒），否则在高并发下仍会形成微秒级的失效簇；也不能太大（如 ±2 小时），否则部分 key 缓存时间过长，导致脏数据滞留。生产环境建议从 ±5% 基础 TTL 起步（24h → ±72min），再根据监控中 expired_keys 的时间分布图动态调整。
