促销开始后缓存大量同时过期，数据库连接池迅速打满；你会如何区分缓存雪崩与热点 Key 问题，并设计缓解和验证方案？

我会先看请求分布和资源指标，判断是大量 Key 同时失效，还是流量集中打到少数 Key 上；两种情况也可能同时发生。

缓存雪崩 通常表现为大量 Key 在相近时间过期，整体缓存命中率突然下降，多个业务请求同时回源，数据库 QPS 和连接池活跃数、等待数一起上升。缓存实例整体不可用或重启也会造成类似现象。 热点 Key 的特征是访问分布明显倾斜：某个或少数 Key 的请求量特别高，可能导致对应 Redis 节点的 CPU、网络或单线程处理能力成为瓶颈；如果缓存未命中或失效，数据库压力也会集中在相关查询上。可以结合 Key 级别访问统计、Redis 节点指标、调用链和数据库 SQL 分布来确认，而不是只看总 QPS。

针对促销场景，我会先做数据库保护：限制回源并发、设置超时和熔断，必要时对非核心查询降级或返回可接受的旧数据，避免连接池被打满。缓存侧按问题分别处理：

对 雪崩 ，给 TTL 加随机抖动，避免批量同一时刻过期；促销前预热关键数据；对可接受短暂不一致的数据使用逻辑过期或后台刷新，过期时优先返回旧值、异步更新。对于缓存整体故障，还要准备限流、降级和