@Cacheable注解如何设置默认过期时间？

Question

在使用Spring的@Cacheable注解时，如何为缓存项设置统一的默认过期时间？虽然@Cacheable本身不直接支持TTL（Time To Live）配置，但实际应用中常结合Redis等缓存中间件实现过期策略。常见的问题是：在未显式指定过期时间的情况下，如何通过RedisCacheManager或自定义CacheResolver全局设置默认TTL？特别是在多环境或微服务架构中，如何确保缓存过期策略的一致性与可维护性？

Answer 1

一、Spring Cache与@Cacheable注解的缓存过期机制解析

在Spring生态中，@Cacheable注解是声明式缓存的核心工具之一，它允许开发者通过简单的注解方式实现方法结果的缓存。然而，该注解本身并未提供直接设置TTL（Time To Live）的能力，这使得缓存项的生命周期管理必须依赖底层缓存中间件，如Redis。

1.1 @Cacheable的基本用法与局限性

@Cacheable用于标记可缓存的方法，其核心属性包括value（缓存名称）、key（缓存键）等。示例如下：

@Cacheable(value = "users", key = "#id")
public User findUserById(Long id) {
    return userRepository.findById(id);
}

上述代码将方法返回值缓存至名为users的缓存中，但未指定过期时间。此时，缓存的TTL由底层缓存管理器决定。

1.2 Redis作为缓存实现时的TTL控制机制

当使用Redis作为缓存存储时，TTL的控制主要通过RedisCacheManager配置实现。Spring Data Redis提供了丰富的配置选项来定义缓存行为。

默认情况下，若未显式设置过期时间，Redis中的缓存项将永不过期，这可能导致内存泄漏或数据陈旧问题。

2.1 配置RedisCacheManager设置全局默认TTL

可通过RedisCacheConfiguration类为所有缓存设置统一的默认过期策略。以下是一个典型的配置示例：

@Configuration
@EnableCaching
public class CacheConfig {

    @Bean
    public RedisCacheManager cacheManager(RedisConnectionFactory connectionFactory) {
        RedisCacheConfiguration defaultConfig = RedisCacheConfiguration.defaultCacheConfig()
            .entryTtl(Duration.ofMinutes(30)) // 全局默认TTL：30分钟
            .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()))
            .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()));

        return RedisCacheManager.builder(connectionFactory)
            .cacheDefaults(defaultConfig)
            .build();
    }
}

此配置确保所有未单独指定TTL的缓存均遵循30分钟的过期规则。

2.2 按缓存名称差异化设置TTL

在复杂系统中，不同业务场景可能需要不同的TTL策略。可通过withInitialCacheConfigurations方法实现精细化控制：

Map<String, RedisCacheConfiguration> configMap = new HashMap<>();
configMap.put("users", defaultConfig.entryTtl(Duration.ofHours(1)));
configMap.put("products", defaultConfig.entryTtl(Duration.ofMinutes(15)));

return RedisCacheManager.builder(connectionFactory)
    .withInitialCacheConfigurations(configMap)
    .cacheDefaults(defaultConfig)
    .build();

3.1 自定义CacheResolver实现动态TTL逻辑

对于更复杂的场景，可实现CacheResolver接口，根据运行时上下文动态选择缓存配置：

@Component
public class CustomCacheResolver implements CacheResolver {
    
    private final RedisCacheManager cacheManager;

    public CustomCacheResolver(RedisCacheManager cacheManager) {
        this.cacheManager = cacheManager;
    }

    @Override
    public Collection<Cache> resolveCaches(CacheOperationInvocationContext context) {
        String methodName = context.getMethod().getName();
        Duration ttl = switch (methodName) {
            case "findUserById" -> Duration.ofMinutes(60);
            case "listProducts" -> Duration.ofMinutes(10);
            default -> Duration.ofMinutes(30);
        };
        
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig().entryTtl(ttl);
        return Collections.singletonList(cacheManager.getCache(context.getCacheName()));
    }
}

3.2 在@Cacheable中使用自定义Resolver

通过cacheResolver属性指定解析器：

@Cacheable(value = "users", cacheResolver = "customCacheResolver")
public User findUserById(Long id) { ... }

4.1 多环境与微服务架构下的缓存策略一致性保障

在分布式系统中，缓存策略的一致性至关重要。建议采用以下实践：

• 将缓存配置抽象为独立的配置模块或starter
• 通过配置中心（如Nacos、Apollo）集中管理TTL参数
• 使用Profile-aware配置区分开发、测试、生产环境
• 建立缓存命名规范，便于策略映射
• 引入监控机制，跟踪缓存命中率与过期情况
• 定期审计缓存使用情况，避免滥用
• 在CI/CD流程中加入缓存配置校验
• 文档化各缓存区域的TTL策略
• 使用AOP增强对缓存操作的审计能力
• 设计降级机制应对缓存失效高峰

4.2 基于配置中心的动态TTL管理方案

结合Spring Cloud Config或Nacos，可实现TTL的热更新：

环境	users缓存TTL	products缓存TTL	orders缓存TTL
dev	5m	2m	10m
test	15m	5m	30m
prod	60m	30m	120m

5.1 缓存过期策略的演进路径

随着系统规模扩大，缓存策略应逐步演进：

1. 初始阶段：统一默认TTL
2. 成长阶段：按业务域划分TTL
3. 成熟阶段：动态策略+配置中心驱动
4. 高级阶段：AI预测型TTL调整
5. 治理阶段：全链路缓存拓扑分析

5.2 使用Mermaid绘制缓存配置决策流程

graph TD
    A[请求进入@Cacheable方法] --> B{是否指定cacheManager?}
    B -- 是 --> C[使用指定cacheManager]
    B -- 否 --> D[使用默认cacheManager]
    C --> E{缓存是否存在?}
    D --> E
    E -- 否 --> F[执行方法体]
    F --> G[写入缓存]
    G --> H[应用TTL策略]
    H --> I[返回结果]
    E -- 是 --> J[检查是否过期]
    J -- 是 --> F
    J -- 否 --> K[返回缓存值]