@cacheable无法实现per-key随机ttl，因其依赖的rediscacheconfiguration仅支持全局固化entryttl，注解层不参与ttl计算；根本原因在于spring cache抽象设计限制，所有key共享同一过期策略。
固定过期时间是缓存雪崩最直接的导火索，必须让 TTL 在基础值上“抖动”起来——但不是用 new Random() 每次生成一个新实例，也不是靠 @Cacheable 的 unless 或硬编码 entryTtl。
为什么 @Cacheable 注解无法实现 per-key 随机 TTL
Spring Cache 的 RedisCacheConfiguration 只允许配置全局 entryTtl，它在初始化时就被固化为一个 Duration 对象，所有 key 共享同一过期策略。你在 @Cacheable 里写 cacheManager = "myCacheManager" 或加 unless="#result == null"，都改变不了这个事实——注解本身不参与 TTL 计算逻辑。
常见错误现象包括：
- 监控发现缓存命中率在整点（如 10:00、11:00）附近断崖式下跌，伴随数据库 QPS 瞬间翻倍
- 日志中大量出现
Cache entry expired at same time for keys: [user:1001, user:1002, ...]类似提示（需自行埋点）
根本原因：你没绕过注解层，而是试图在声明式缓存上“打补丁”。
用 RedisTemplate 手动 set + 偏移区间抖动
这是最可控、最易验证的方式。核心是把“随机”从无意义的 nextInt(3600) 升级为有业务语义的偏移区间抖动。
推荐做法：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 定义基础 TTL（如 3600 秒）和波动半径（如 ±180 秒），用
ThreadLocalRandom.current().nextInt(-180, 181)生成偏移量 - 避免在方法体内
new Random()—— 它可能因种子相同导致多线程下生成重复序列 - 调用
redisTemplate.opsForValue().set(key, value, ttl, TimeUnit.SECONDS)，其中ttl是计算后的结果 - 对冷数据可额外叠加
expireAfterAccess（需配合 Caffeine 使用），但 Redis 层只管写入时的绝对 TTL
示例片段：
int baseTtl = 3600;
int jitter = ThreadLocalRandom.current().nextInt(-180, 181);
long finalTtl = Math.max(60, baseTtl + jitter); // 不低于 1 分钟
redisTemplate.opsForValue().set("user:" + userId, json, finalTtl, TimeUnit.SECONDS);
自定义 RedisCacheWriter 实现全自动抖动
如果项目已重度依赖 @Cacheable，又不想大规模改业务代码，唯一可行路径是替换底层写入逻辑。
关键点：
- 继承
DefaultRedisCacheWriter，重写put方法，在调用super.put(...)前对传入的timeout参数做扰动 - 注入时通过
RedisCacheConfiguration.cacheWriter(...)替换默认实例 - 注意：该方式对所有
@Cacheable生效，无法按cacheNames区分策略；若需差异化（比如"users"抖动 ±180s，"configs"抖动 ±30s），得在put中解析cacheName字符串做路由 - 别忘了在配置中启用
usePrefix()和computePrefixWith(...)，否则 key 冲突风险上升
Caffeine 本地缓存如何配合抖动防雪崩前哨
Caffeine 本身不支持运行时单 entry 动态 TTL，但它能用组合策略形成“软抖动”效果，作为 Redis 的第一道缓冲。
必须做的几件事：
- 开启
recordStats()：否则你根本看不到命中率是否异常跌落——雪崩前兆常是cache.getIfPresent()命中率从 95% 突降到 40% - 同时设置
expireAfterWrite(Duration.ofMinutes(5))和expireAfterAccess(Duration.ofMinutes(2))，前者防脏数据滞留，后者自动淘汰低频 key，客观上稀释了集中失效压力 - 别把它当 Redis 替代：Caffeine 是进程内、不共享、不一致的，只适合读多写少且容忍短时 stale 的场景（如地区字典、用户权限快照）
真正难的不是让 TTL 变“乱”，而是让“乱”有边界、可监控、可回滚。抖动不是为了随机而随机，而是为了让系统负载曲线更平滑——这点容易被忽略。
