同一业务域的key必须避免统一TTL，跨国多地域场景下应按地域注入偏移因子（如region_id绑定随机种子），分批预热、错峰过期，并确保本地缓存TTL与Redis非整除以拉长错峰周期。
同一业务域的 key 必须避免统一 TTL
跨国多地域场景下，各区域流量高峰不重叠（如亚太早 8 点、欧美晚 8 点），但若所有缓存都设 EXPIRE key 3600，就等于把全球失效压力对齐到同一秒——哪怕 Redis 集群健康，数据库照样被跨时区请求轮番击穿。
正确做法是按地域维度注入偏移因子：比如基础 TTL 设为 3600 秒，再叠加 random.nextInt(120, 600)，但这个随机种子需绑定 region_id 或 dc_code，确保同地域 key 的过期分布相似、跨地域错峰明显。别用全局 new Random()，它在高并发下可能产出重复序列。
- Java 示例：
int offset = Math.abs(regionCode.hashCode()) % 480 + 120;，比纯随机更可控 - 避免在 K8s Pod 启动时批量预热全量 key 并统一设 TTL——预热脚本必须按地域分批执行，每批间隔 ≥ 2 分钟
- 监控项要加标签：
redis_expired_keys_total{region="us-east"}，而不是只看总量
本地缓存 TTL 必须短于 Redis TTL 且不可对齐
多级缓存不是简单叠加两层，而是构建时间梯度防御。如果 Caffeine 本地缓存设 expireAfterWrite(300, TimeUnit.SECONDS)，Redis 又设 3600，看似合理，但一旦本地缓存和 Redis 在同一分钟内集体刷新（比如都从整点开始计时），就会在第 300 秒触发第一波穿透、第 3600 秒触发第二波穿透，形成双峰冲击。
必须让本地缓存 TTL 是「非整除」关系：比如 Redis TTL = 3600，本地就设 293 秒或 437 秒——质数更安全，能拉长错峰周期。同时禁止用 System.currentTimeMillis() 做本地缓存刷新触发器，改用 System.nanoTime() 配合滑动窗口。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
预热脚本必须带地域隔离与渐进节奏
跨国系统上线或大促前的数据预热，最容易引发雪崩。常见错误是写一个脚本遍历全部 hot_key_*，统一 SET key value EX 3600，然后在所有地域同时跑。
真实可行的节奏是：
- 预热 key 按
region标签分组，每个分组单独加载 - 每组内 key 按热度排序，前 5% 热 key 先加载，TTL 设为
base + 0~60；其余 key 分 3 批，间隔 90 秒，TTL 偏移递增 - 脚本启动时读取配置中心的
cache.warmup.enabled[region]开关，禁用某地域即跳过该批次 - 禁止使用
redis-cli --pipe批量导入——它不支持 per-key TTL，必须走 client SDK 调用set(key, value, expire)
Redis Cluster 不解决过期集中问题，但放大配置错误风险
很多人以为上了 Redis Cluster 就高枕无忧，其实集群反而会掩盖 TTL 设计缺陷。比如你误将 cluster-require-full-coverage yes，某个分片短暂不可用时，整个集群拒绝写入，所有缓存写失败，等恢复后大量请求瞬间涌向 DB——这比单节点雪崩更难定位。
关键检查点：
- 确认
cluster-require-full-coverage no已生效，用CLUSTER INFO查cluster_state:ok且cluster_slots_assigned接近 16384 - 客户端必须启用 slot-aware 路由，禁用
redis.clients.jedis.Jedis（非 JedisCluster），否则会路由错误导致部分 key 写入失败却不报错 - 密码配置必须全集群一致：
requirepass和masterauth若不匹配，从节点无法同步，主节点过期 key 清理后，从节点仍持有旧值，造成脏读+穿透双重风险
LocalDateTime.now() 或依赖 JVM 默认时区做 TTL 计算，就可能在某次部署后突然出现大批 key 同时失效。TTL 必须是纯数值计算，不依赖任何运行时环境的时间上下文。 
