如果有大量的key需要设置同一时间过期，一般需要注意什么？

更多面试题请看这里：https://interview.raoyunsoft.com/
面试题专栏会持续更新欢迎关注订阅

当大量 Redis key 在同一时间点过期时，会引发两个核心问题：

⚠️ 风险隐患

1. 数据库雪崩效应

   • 所有过期 key 的请求会在同一秒穿透到后端数据库
   • 数据库瞬间承受数十倍甚至百倍的查询压力
   • 可能导致数据库连接池耗尽、CPU 飙升至 100%
   • 最终引发数据库崩溃，表现为 502 服务不可用错误

2. Redis 服务卡顿

   • Redis 需要同步清理海量过期 key
   • 大量内存回收操作占用主线程资源
   • 导致其他命令执行延迟增加（如 SET/GET 操作）
   • 表现为服务响应时间突增，监控出现毛刺

🛡️ 解决方案与最佳实践

1. 过期时间随机化（核心方案）

   // 基础过期时间 + 随机偏移量（示例代码）
   int baseExpire = 3600; // 基础1小时
   int randomOffset = (int)(Math.random() * 300); // 0-5分钟随机值
   redis.set(key, value, baseExpire + randomOffset);
   

   • 随机范围建议：基础过期时间的 10%-20%（如 1小时±10分钟）
   • 效果：将过期峰值请求分散到 10-20 分钟的时间窗口

2. 逻辑过期补偿机制

   • 在 value 中存储逻辑过期时间戳
   • 实际 TTL 设置为逻辑 TTL 的 1.2-1.5 倍
   • 客户端发现逻辑过期后异步刷新缓存

3. 多级缓存兜底

   缓存层级	过期策略	作用
   本地缓存	短时固定过期	扛过Redis瞬时压力
   Redis	随机过期	分散数据库压力
   数据库	-	最终数据源

4. 监控预警配置

   • Redis 监控项：expired_keys 速率突变告警
   • 数据库监控：QPS 突增阈值告警
   • 设置 Key 过期分布仪表盘（按小时聚合）

🔍 特殊场景处理

• 定时预热场景：在业务低峰期分批更新 key，避免集中失效
• 冷启动场景：采用渐进式过期策略，首轮设置短 TTL（5-10分钟），后续逐步延长
• 集群环境：在分片节点间采用差异化的随机因子算法，避免所有分片同时触发过期