热点缓存过期或 Redis 暂时不可用时，大量请求可能同时查询数据库。缓存设计不仅需要命中路径，还需要解释回源、重建和故障期间的容量行为。
先识别热点与失效方式
确定哪些键访问集中、是否大量键在同一时刻过期，以及缓存不可用时请求会怎样处理。没有基线时，很难判断需要优化单个热点还是整个缓存更新策略。
限制并发重建
可按场景评估请求合并、受控刷新或有边界的回源并发。多实例之间是否需要协调，应结合数据成本与一致性要求决定。不能只在单进程加锁，就假定全站只有一次回源。
旧数据能否继续使用要由业务决定
商品描述与账户余额对数据陈旧的容忍不同。允许短期使用旧值时，要写清有效范围与刷新方式；不能在没有确认的交易场景下悄悄返回陈旧结果。
验收冷缓存和故障恢复
清空测试热点或停止缓存依赖，观察数据库是否仍在可承受范围、错误是否可控。恢复缓存时也检查重建流量，避免故障恢复触发第二次压力峰值。
常见问题：所有缓存过期时间加随机值就够了吗？
随机化能缓解部分同时失效，但不能替代热点重建、回源限制和故障降级设计。
技术参考：微软：Cache-Aside 模式。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果内部团队需要把这些约定落到可运行的工程中，可以通过微服务基础架构建设沟通接口、公共能力与交接范围，先以一个业务场景验证方案。