导航：首页 > 开发技术 >

Spring Boot中如何配置多个TTL缓存

发表于：2024-11-24 作者：千家信息网编辑

千家信息网最后更新 2024年11月24日，这篇文章主要介绍了Spring Boot中如何配置多个TTL缓存，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。1. 研究案例让我们从问

千家信息网最后更新 2024年11月24日Spring Boot中如何配置多个TTL缓存

这篇文章主要介绍了Spring Boot中如何配置多个TTL缓存，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。

1. 研究案例

让我们从问题的定义开始。我们想象中的应用程序需要缓存两个不同的 REST 端点，但其中一个应该比另一个更频繁地过期。考虑以下外观实现：

@Serviceclass ForeignEndpointGateway {     private RestTemplate restTemplate;     ForeignEndpointGateway(RestTemplate restTemplate) {        this.restTemplate = restTemplate;    }         @Cacheable("messages")    public Message findMessage(long id) {        String url ="http://somedomain.com/messages/" + id;        return restTemplate.getForObject(url, Message.class);    }     @Cacheable("notifications")    public Notification findNotification(long id) {        String url ="http://somedomain.com/notifications/" + id;        return restTemplate.getForObject(url, Notification.class);    } }

@Cacheable注释标记方法Spring的缓存机制。值得一提的是，缓存的方法必须是公开的。每个注解都指定了应该用于特定方法的相应缓存的名称。

缓存实例只不过是一个简单的键值容器。在我们的例子中，键是基于输入参数创建的，值是方法的结果，但它不必那么简单。Spring 提供的缓存抽象允许更多，但这是另一篇文章的主题。如果你对细节感兴趣，我推荐你参考文档。让我们坚持我们的主要目标，即为两个声明的缓存定义不同的 TTL 值。

2. 常用缓存设置

将@Cacheable注释放在方法上并不是在应用程序中运行缓存机械化所需的唯一内容。根据所选的提供商，可能会有几个额外的步骤。

2.1. 开启 Spring 缓存

无论您选择哪个提供程序，设置的起点始终是将@EnableCaching注释添加到您的配置类之一，通常是主应用程序类。这会在您的 Spring 上下文中注册所有必需的组件。

@SpringBootApplication@EnableCachingpublic class TtlCacheApplication {    // content omitted for clarity}

2.2. 必需的依赖项

在使用@EnableCaching注释的常规 Spring 应用程序中，需要开发人员提供CacheManager类型的 bean 。幸运的是，Spring Boot 缓存启动器提供了默认管理器，并根据类路径上可用的依赖项创建了一个适当的缓存提供程序，在我们的例子中是 Caffeine 库。

    org.springframework.boot    spring-boot-starter-cache    com.github.ben-manes.caffeine    caffeine

2.3. 基本配置

Spring Boot 支持的大多数缓存提供程序可以使用专用的应用程序属性进行调整。要为演示应用程序所需的两个缓存设置 TTL，我们可以使用以下值：

spring.cache.cache-names=messages,notificationsspring.cache.caffeine.spec=maximumSize=100,expireAfterAccess=1800s

以一种非常简单的方式，我们将缓存的 TTL 设置为 30 分钟，并将它们的容量设置为 100。但是，这种配置的主要问题是所有缓存都使用相同的设置。不可能为每个缓存设置不同的规范。他们都需要共享一个全局的。如果您不介意此类限制，则可以进行基本设置。否则，您应该继续阅读下一部分。

3.区分缓存

Spring Boot 有效地处理流行的配置，但我们的场景不属于这个幸运组。为了根据我们的需要自定义缓存，我们需要超越预定义的 bean 并编写一些自定义初始化代码。

3.1. 自定义缓存管理器

无需禁用 Spring Boot 提供的默认配置，因为我们只能覆盖一个必要的对象。通过定义名为cacheManager的 bean，我们替换了 Spring Boot 提供的 bean 。下面我们创建两个缓存。第一个称为消息，其过期时间等于 30 分钟。另一个名为通知的值存储 60 分钟。当您创建自定义缓存管理器时，application.properties 中的设置（之前在基本示例中介绍过）不再使用，可以安全地删除。

@Beanpublic CacheManager cacheManager(Ticker ticker) {    CaffeineCache messageCache = buildCache("messages", ticker,30);    CaffeineCache notificationCache = buildCache("notifications", ticker,60);    SimpleCacheManager manager =new SimpleCacheManager();    manager.setCaches(Arrays.asList(messageCache, notificationCache));    return manager;} private CaffeineCache buildCache(String name, Ticker ticker,int minutesToExpire) {    return new CaffeineCache(name, Caffeine.newBuilder()                .expireAfterWrite(minutesToExpire, TimeUnit.MINUTES)                .maximumSize(100)                .ticker(ticker)                .build());} @Beanpublic Ticker ticker() {    return Ticker.systemTicker();}

Caffeine 库带有一个方便的缓存构建器。在我们的演示中，我们只关注不同的 TTL 值，但也可以根据需要自定义其他选项（例如容量或访问后非常有用的到期时间）。

在上面的例子中，我们还创建了ticker bean，我们的缓存共享它。自动收报机负责跟踪时间的流逝。实际上，将Ticker类型的实例传递给缓存构建器并不是强制性的，如果没有提供，Caffeine 会创建一个。但是，如果我们想为我们的解决方案编写测试，单独的 bean 将更容易存根。

3.2. TTL缓存测试

我们在集成测试中需要的第一件事是一个带有假代码的配置类，它允许模拟时间流逝。Caffeine 库本身不提供这样的代码，但文档中提到了 guava-testlib，我们需要将其声明为我们项目的依赖项。

    com.google.guava    guava-testlib    20.0    test

如果测试类中存在一个内部静态配置类，则 Spring Boot 1.4.0 中添加的@SpringBootTest注释会自动检测并利用内部静态配置类。通过导入主配置类，我们保留了原始项目设置，并仅用假的替换了股票代码实例。

@RunWith(SpringRunner.class)@SpringBootTestpublic class MessageRepositoryTest {     @Configuration    @Import(TtlCacheApplication.class)    public static class TestConfig {         static FakeTicker fakeTicker =new FakeTicker();         @Bean        public Ticker ticker() {            return fakeTicker::read;        }     }}

我们将在缓存网关类使用的RestTemplate实例上使用监控，以观察对真实 REST 端点的可能调用数量。监控应该返回一些存根值以防止实际调用发生。

private static final long MESSAGE_ID =1;private static final long NOTIFICATION_ID =2; @SpyBeanprivate RestTemplate restTemplate;@Autowiredprivate ForeignEndpointGateway gateway; @Beforepublic void setUp()throws Exception {    Message message = stubMessage(MESSAGE_ID);    Notification notification = stubNotification(NOTIFICATION_ID);    doReturn(message)            .when(restTemplate)            .getForObject(anyString(), eq(Message.class));    doReturn(notification)            .when(restTemplate)            .getForObject(anyString(), eq(Notification.class));}

最后，我们可以用我们的快乐路径场景编写一个测试，以确认 TTL 配置是否符合我们的预期。

@Testpublic void shouldUseCachesWithDifferentTTL()throws Exception {    // 0 minutes    foreignEndpointGateway.findMessage(MESSAGE_ID);    foreignEndpointGateway.findNotification(NOTIFICATION_ID);    verify(restTemplate, times(1)).getForObject(anyString(), eq(Message.class));    verify(restTemplate, times(1)).getForObject(anyString(), eq(Notification.class));    // after 5 minutes    TestConfig.fakeTicker.advance(5, TimeUnit.MINUTES);    foreignEndpointGateway.findMessage(MESSAGE_ID);    verify(restTemplate, times(1)).getForObject(anyString(), eq(Message.class));    // after 35 minutes    TestConfig.fakeTicker.advance(30, TimeUnit.MINUTES);    foreignEndpointGateway.findMessage(MESSAGE_ID);    foreignEndpointGateway.findNotification(NOTIFICATION_ID);    verify(restTemplate, times(2)).getForObject(anyString(), eq(Message.class));    verify(restTemplate, times(1)).getForObject(anyString(), eq(Notification.class));    // after 65 minutes    TestConfig.fakeTicker.advance(30, TimeUnit.MINUTES);    foreignEndpointGateway.findNotification(NOTIFICATION_ID);    verify(restTemplate, times(2)).getForObject(anyString(), eq(Notification.class));}

一开始，Message和Notification对象都是从端点获取并放置在缓存中。5 分钟后，将再次调用Message对象。由于消息缓存 TTL 配置为 30 分钟，我们预计将从缓存中获取该值，并且不会调用端点。再过 30 分钟后，我们预计缓存的消息已过期，我们通过对端点的另一次调用来确认这一点。但是，通知缓存已配置为将值保留 60 分钟。通过再次尝试获取通知，我们确认另一个缓存仍然有效。最后，自动收报机再前进 30 分钟，从测试开始算起总共 65 分钟。我们验证通知也已过期并从缓存中删除。