Caffeine
[TOC]
Caffeine
介绍
各位移步项目Github,查阅即可,有中文版和英文版。
Github:https://github.com/ben-manes/caffeine/wiki
实现
SpringBoot整合
自动配置整合
添加依赖:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.6.3</version>
<relativePath/>
</parent>
<!-- ... -->
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!-- Cache -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<dependency>
<groupId>com.github.ben-manes.caffeine</groupId>
<artifactId>caffeine</artifactId>
<version>2.9.3</version>
</dependency>
</dependencies>
<!-- ... -->
</project>
启动类加上@EnableCaching注解,此注解的含义是开启Cache相关的注解:
配置文件:
到此,自动配置整合完毕,后续使用如下:
手动配置整合
添加依赖:
缓存配置类:
到此,手动配置整合完毕,后续使用如下:
SpringBoot健康检查
官方文档:https://docs.spring.io/spring-boot/docs/2.5.4/reference/htmlsingle/#actuator.metrics.supported.cache
重要:下方是官方的原话,大致的意思就是,Caffeine Metrics 已经支持自动配置,但是只能在启动的时候绑定。如果有一些Cache是动态生成的,则需要手动结合CacheMetricsRegistrar实现。
Cache Metrics
Auto-configuration enables the instrumentation of all available
Caches on startup with metrics prefixed withcache. Cache instrumentation is standardized for a basic set of metrics. Additional, cache-specific metrics are also available.The following cache libraries are supported:
Caffeine
EhCache 2
Hazelcast
Any compliant JCache (JSR-107) implementation
Redis
Metrics are tagged by the name of the cache and by the name of the
CacheManagerthat is derived from the bean name.Note
Only caches that are configured on startup are bound to the registry. For caches not defined in the cache’s configuration, e.g. caches created on-the-fly or programmatically after the startup phase, an explicit registration is required. A
CacheMetricsRegistrarbean is made available to make that process easier.
SpringBoot实现
版本:
自动配置:
MetricsAutoConfiguration
Cache相关实现:
CacheMetricsRegistrarConfiguration
CacheMeterBinderProvidersConfiguration CaffeineCacheMeterBinderProvider
我们直接看Registrar是如何注册Cache监控指标的,入口:org.springframework.boot.actuate.autoconfigure.metrics.cache.CacheMetricsRegistrarConfiguration
核心方法:
MetricsRegistrar:org.springframework.boot.actuate.metrics.cache.CacheMetricsRegistrar
核心方法:
CacheMeterBinderProvider:org.springframework.boot.actuate.metrics.cache.CaffeineCacheMeterBinderProvider,实现了接口org.springframework.boot.actuate.metrics.cache.CacheMeterBinderProvider,下方为两者的类图:

核心方法:
Micrometer实现
版本:
MeterBinder:io.micrometer.core.instrument.binder.cache.CaffeineCacheMetrics,继承io.micrometer.core.instrument.binder.cache.CacheMeterBinder,下方为两者的类图:

核心方法:
原理
淘汰策略
W-Tiny LFU

LRU
LRU(Least recently used,最近最少使用)算法根据数据的历史访问记录来进行淘汰数据,其核心思想是:如果数据最近被访问过,那么将来被访问的几率也更高。

Tiny LFU
Segmented LRU (SLRU)
从维基百科摘抄:
SLRU cache is divided into two segments, a probationary segment and a protected segment. Lines in each segment are ordered from the most to the least recently accessed. Data from misses is added to the cache at the most recently accessed end of the probationary segment. Hits are removed from wherever they currently reside and added to the most recently accessed end of the protected segment. Lines in the protected segment have thus been accessed at least twice. The protected segment is finite, so migration of a line from the probationary segment to the protected segment may force the migration of the LRU line in the protected segment to the most recently used (MRU) end of the probationary segment, giving this line another chance to be accessed before being replaced. The size limit on the protected segment is an SLRU parameter that varies according to the I/O workload patterns. Whenever data must be discarded from the cache, lines are obtained from the LRU end of the probationary segment
SLRU缓存分为两个段,一个试用段和一个保护段。 每个段中的行按最近访问次数最多到最少访问的顺序排列。 未命中的数据被添加到试用段最近访问端的缓存中。 命中将从它们当前所在的任何位置删除,并添加到受保护段的最近访问端。 因此,受保护段中的行至少被访问了两次。 受保护段是有限的,因此将一条线路从试用段迁移到受保护段可能会迫使受保护段中的 LRU 线路迁移到试用段的最近使用 (MRU) 端,从而给这条线路另一个机会 在被替换之前访问。 受保护段的大小限制是根据 I/O 工作负载模式而变化的 SLRU 参数。 每当必须从缓存中丢弃数据时,都会从试用段的 LRU 端获取行
Last updated