@cacheable不支持ttl配置，因spring cache抽象层无此字段；需通过rediscacheconfiguration分cachename设基础ttl，并用randomizedttlcachewriter在put时加±10%随机偏移。
为什么直接在@Cacheable里加随机TTL会编译失败
因为 @Cacheable 注解压根没有 ttl、timeToLive 或任何类似字段——Spring Cache抽象层不支持单次调用动态设TTL。你写 @Cacheable(timeToLive = 60)，IDE会直接报错：*Unknown property*。这不是配置漏了，是API根本不存在。
用RedisCacheConfiguration按cacheName分组配TTL+随机偏移
真正可控的方式，是在构建每个 RedisCacheManager 时，对不同缓存名（如 "user"、"product"）分别配置基础TTL，并在运行时加随机扰动。关键不是“覆盖注解”，而是接管缓存写入前的 RedisCacheWriter。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 定义一个
RandomizedTtlCacheWriter，包装原始RedisCacheWriter，在put()时对传入的Duration做 ±10% 随机浮动 - 每个
CacheManager绑定独立的RedisCacheConfiguration，其中entryTtl设为基础值（比如Duration.ofMinutes(30)） - 确保
cacheDefaults显式设置，否则新 cache 实例会 fallback 到全局默认配置，随机逻辑就失效了 - 别依赖
set(K,V,Duration)——它底层走SETEX，无法复用已存在 key；要用set()+expire()两步，才能对已有 key 动态改 TTL
自定义@CacheTTL注解 + AOP拦截实现方法级TTL扰动
如果你坚持用 @Cacheable 声明式风格，又想每个方法能带自己的基础TTL和随机范围，就得自己造轮子：定义 @CacheTTL 注解，再用 AOP 在 @Cacheable 执行前注入随机化逻辑。
-
@CacheTTL(value = 1800, jitter = 300)表示基础 30 分钟，±5 分钟随机波动 - AOP 切点监听
@Cacheable方法执行，从注解提取jitter，生成Duration后塞进上下文或 ThreadLocal - 配合自定义
RedisCacheWriter，在写入时读取该 Duration 并应用随机偏移 - 注意：AOP 不会自动作用于内部调用（private / this. 调用），且需确保切面顺序早于 Spring Cache 拦截器
Redis端防雪崩的硬性提醒：别只靠Java层随机
Java 层加随机只是第一道防线。Redis 自身的过期清理机制才是最终保障——它靠“惰性删除 + 定期采样”双策略，但默认每秒只扫 10 次，每次最多检查 20 个键。如果大量 key 的 TTL 被设成同一整点（比如都设 EXPIREAT 1716742800），那一秒内 Redis 可能突然被过期扫描压垮。
- 务必在业务写入时用
redisTemplate.expire(key, randomSeconds, TimeUnit.SECONDS)，而不是统一算好时间戳再用expireAt() - 监控
expired_keys指标（redis-cli INFO stats | grep expired_keys），如果该值长期为 0 或突增 10 倍，说明随机没生效或采样力度不够 - 高并发场景下，
hz参数建议从默认 10 调到 5～8，避免定时任务抢 CPU；active-expire-effort可设为 2，平衡清理力度与性能
new Random().nextInt(60) 就完事。它必须贯穿从注解解析、缓存写入、Redis命令下发到服务端过期调度的全链路，任一环节断掉，雪崩风险照旧。
