자세한 내용은 다음과 같습니다.
Spring Cache를 배우기 전에는 캐싱을 하드코딩해서 사용하는 경우가 많았습니다.
실제적인 예를 들어보겠습니다. 사용자 정보의 쿼리 효율성을 높이기 위해 사용자 정보에 대한 캐싱을 사용합니다.
@Autowire
private UserMapper userMapper;
@Autowire
private RedisCache redisCache;
//查询用户
public User getUserById(Long userId) {
//定义缓存key
String cacheKey = "userId_" + userId;
//先查询redis缓存
User user = redisCache.get(cacheKey);
//如果缓存中有就直接返回，不再查询数据库
if (user != null) {
return user;
}
//没有再查询数据库
user = userMapper.getUserById(userId);
//数据存入缓存，这样下次查询就能到缓存中获取
if (user != null) {
stringCommand.set(cacheKey, user);
}
return user;
}많은 학생들이 비슷한 스타일로 코드를 작성했다고 생각합니다. 사용자 중심의 절차적 프로그래밍 사고는 매우 이해하기 쉽습니다. 하지만 여기에는 몇 가지 단점도 있습니다.
코드가 충분히 우아하지 않습니다. 비즈니스 로직에는 저장, 읽기, 수정, 삭제라는 네 가지 일반적인 작업이 있습니다. 각 작업은 캐시 키를 정의하고 캐시 명령의 API를 호출해야 하며, 이로 인해 많은 중복 코드가 생성됩니다.
캐시 작업과 비즈니스 로직 간의 코드 결합이 높으며 비즈니스 로직에 매우 방해가 됩니다. 침입성은 주로 다음 두 가지 사항을 반영합니다.
개발 및 공동 디버깅 단계에서는 캐시를 제거해야 하며 캐시 작업 코드에 대해서는 주석만 달거나 일시적으로 삭제할 수 있습니다. 이 역시 오류가 발생하기 쉽습니다;
일부 시나리오에서는 캐시를 구성 요소로 교체해야 하며 각 캐시 구성 요소에는 자체 API가 있으며 교체 비용이 상당히 높습니다.
@Mapper
public interface UserMapper {
/**
* 根据用户id获取用户信息
*
* 如果缓存中有直接返回缓存数据，如果没有那么就去数据库查询，查询完再插入缓存中，这里缓存的key前缀为cache_user_id_，+传入的用户ID
*/
@Cacheable(key = "'cache_user_id_' + #userId")
User getUserById(Long userId);
} @Autowire
private UserMapper userMapper;
//查询用户
public User getUserById(Long userId) {
return userMapper.getUserById(userId);
}Cache와 CacheManager 두 개뿐입니다.Cache和CacheManager该接口定义提供缓存的具体操作，比如缓存的放入、读取、清理：
package org.Springframework.cache;
import java.util.concurrent.Callable;
public interface Cache {
// cacheName，缓存的名字，默认实现中一般是CacheManager创建Cache的bean时传入cacheName
String getName();
//得到底层使用的缓存，如Ehcache
Object getNativeCache();
// 通过key获取缓存值，注意返回的是ValueWrapper，为了兼容存储空值的情况，将返回值包装了一层，通过get方法获取实际值
ValueWrapper get(Object key);
// 通过key获取缓存值，返回的是实际值，即方法的返回值类型
<T> T get(Object key, Class<T> type);
// 通过key获取缓存值，可以使用valueLoader.call()来调使用@Cacheable注解的方法。当@Cacheable注解的sync属性配置为true时使用此方法。
// 因此方法内需要保证回源到数据库的同步性。避免在缓存失效时大量请求回源到数据库
<T> T get(Object key, Callable<T> valueLoader);
// 将@Cacheable注解方法返回的数据放入缓存中
void put(Object key, Object value);
// 当缓存中不存在key时才放入缓存。返回值是当key存在时原有的数据
ValueWrapper putIfAbsent(Object key, Object value);
// 删除缓存
void evict(Object key);
// 清空缓存
void clear();
// 缓存返回值的包装
interface ValueWrapper {
// 返回实际缓存的对象
Object get();
}
}主要提供Cache实现bean的创建，每个应用里可以通过cacheName来对Cache进行隔离，每个cacheName对应一个Cache实现。
package org.Springframework.cache;
import java.util.Collection;
public interface CacheManager {
// 通过cacheName创建Cache的实现bean，具体实现中需要存储已创建的Cache实现bean，避免重复创建，也避免内存缓存
//对象（如Caffeine）重新创建后原来缓存内容丢失的情况
Cache getCache(String name);
// 返回所有的cacheName
Collection<String> getCacheNames();
}@Cacheable：主要应用到查询数据的方法上。
public @interface Cacheable {
// cacheNames，CacheManager就是通过这个名称创建对应的Cache实现bean
@AliasFor("cacheNames")
String[] value() default {};
@AliasFor("value")
String[] cacheNames() default {};
// 缓存的key，支持SpEL表达式。默认是使用所有参数及其计算的hashCode包装后的对象（SimpleKey）
String key() default "";
// 缓存key生成器，默认实现是SimpleKeyGenerator
String keyGenerator() default "";
// 指定使用哪个CacheManager,如果只有一个可以不用指定
String cacheManager() default "";
// 缓存解析器
String cacheResolver() default "";
// 缓存的条件，支持SpEL表达式，当达到满足的条件时才缓存数据。在调用方法前后都会判断
String condition() default "";
// 满足条件时不更新缓存，支持SpEL表达式，只在调用方法后判断
String unless() default "";
// 回源到实际方法获取数据时，是否要保持同步，如果为false，调用的是Cache.get(key)方法；如果为true，调用的是Cache.get(key, Callable)方法
boolean sync() default false;
}@CacheEvict：清除缓存，主要应用到删除数据的方法上。相比Cacheable多了两个属性
public @interface CacheEvict {
// ...相同属性说明请参考@Cacheable中的说明
// 是否要清除所有缓存的数据，为false时调用的是Cache.evict(key)方法；为true时调用的是Cache.clear()方法
boolean allEntries() default false;
// 调用方法之前或之后清除缓存
boolean beforeInvocation() default false;
}@CachePut：放入缓存，主要用到对数据有更新的方法上。属性说明参考@Cacheable
@Caching：用于在一个方法上配置多种注解
@EnableCaching：启用Spring cache缓存，作为总的开关，在SpringBoot的启动类或配置类上需要加上此注解才会生效
我们知道关系数据库(Mysql)数据最终存储在磁盘上，如果每次都从数据库里去读取，会因为磁盘本身的IO影响读取速度，所以就有了
像redis这种的内存缓存。
通过内存缓存确实能够很大程度的提高查询速度，但如果同一查询并发量非常的大，频繁的查询redis，也会有明显的网络IO上的消耗，
那我们针对这种查询非常频繁的数据(热点key)，我们是不是可以考虑存到应用内缓存，如：caffeine。
当应用内缓存有符合条件的数据时，就可以直接使用，而不用通过网络到redis中去获取，这样就形成了两级缓存。
应用内缓存叫做一级缓存，远程缓存（如redis）叫做二级缓存。
整个流程如下
流程看着是很清新，但其实二级缓存需要考虑的点还很多。
1.如何保证分布式节点一级缓存的一致性？
我们说一级缓存是应用内缓存，那么当你的项目部署在多个节点的时候，如何保证当你对某个key进行修改删除操作时，使其它节点
的一级缓存一致呢？
2.是否允许存储空值？
这个确实是需要考虑的点。因为如果某个查询缓存和数据库中都没有，那么就会导致频繁查询数据库，导致数据库Down,这也是我们
常说的缓存穿透。
但如果存储空值呢，因为可能会存储大量的空值，导致缓存变大，所以这个最好是可配置，按照业务来决定是否开启。
3.是否需要缓存预热？이 인터페이스는 다음을 제공하는 특정 작업을 정의합니다. 예를 들어 캐시 배치, 읽기 및 정리:
FIFO：先进先出。选择最先进入的数据优先淘汰。 LRU：最近最少使用。选择最近最少使用的数据优先淘汰。 LFU：最不经常使用。选择在一段时间内被使用次数最少的数据优先淘汰。
<dependency>
<groupId>com.jincou</groupId>
<artifactId>redis-caffeine-cache-starter</artifactId>
<version>1.0.0</version>
</dependency>@Cacheable: 주로 데이터 쿼리 방법에 적용됩니다. 🎜# 二级缓存配置
# 注：caffeine 不适用于数据量大，并且缓存命中率极低的业务场景，如用户维度的缓存。请慎重选择。
l2cache:
config:
# 是否存储空值，默认true，防止缓存穿透
allowNullValues: true
# 组合缓存配置
composite:
# 是否全部启用一级缓存，默认false
l1AllOpen: false
# 是否手动启用一级缓存，默认false
l1Manual: true
# 手动配置走一级缓存的缓存key集合，针对单个key维度
l1ManualKeySet:
- userCache:user01
- userCache:user02
- userCache:user03
# 手动配置走一级缓存的缓存名字集合，针对cacheName维度
l1ManualCacheNameSet:
- userCache
- goodsCache
# 一级缓存
caffeine:
# 是否自动刷新过期缓存 true 是 false 否
autoRefreshExpireCache: false
# 缓存刷新调度线程池的大小
refreshPoolSize: 2
# 缓存刷新的频率(秒)
refreshPeriod: 10
# 写入后过期时间(秒)
expireAfterWrite: 180
# 访问后过期时间(秒)
expireAfterAccess: 180
# 初始化大小
initialCapacity: 1000
# 最大缓存对象个数，超过此数量时之前放入的缓存将失效
maximumSize: 3000
# 二级缓存
redis:
# 全局过期时间，单位毫秒，默认不过期
defaultExpiration: 300000
# 每个cacheName的过期时间，单位毫秒，优先级比defaultExpiration高
expires: {userCache: 300000,goodsCache: 50000}
# 缓存更新时通知其他节点的topic名称 默认 cache:redis:caffeine:topic
topic: cache:redis:caffeine:topic@CacheEvict: 캐시 지우기, 주로 데이터 삭제에 사용됩니다. Cacheable에 비해 두 가지 속성🎜/**
* 启动类
*/
@EnableCaching
@SpringBootApplication
public class CacheApplication {
public static void main(String[] args) {
SpringApplication.run(CacheApplication.class, args);
}
}@CachePut이 더 있습니다. 캐시에 저장하고 주로 데이터 업데이트에 사용됩니다. 속성 설명은 @Cacheable🎜🎜@Caching: 하나의 메서드에서 여러 주석을 구성하는 데 사용됩니다.🎜🎜@EnableCaching: Spring 캐시 캐시를 일반 스위치로 활성화합니다. , in 이 주석을 적용하려면 SpringBoot의 시작 클래스 또는 구성 클래스에 추가해야 합니다. 3. 두 번째 수준 캐시를 사용할 때 고려해야 할 몇 가지 문제는 무엇입니까? 🎜🎜관계형 데이터베이스(Mysql) 데이터는 결국 디스크에 저장된다는 것을 우리는 알고 있다. 매번 데이터베이스에서 읽어오면 디스크 자체의 IO에 따라 읽기 속도가 영향을 받기 때문에 redis와 같은 🎜🎜메모리가 있다. .캐시. 🎜🎜메모리 캐싱은 실제로 쿼리 속도를 크게 향상시킬 수 있지만, 동일한 쿼리의 동시성이 매우 크고 Redis 쿼리가 빈번한 경우 네트워크 IO 소비도 분명해집니다. 🎜🎜그런 다음 우리는 이런 종류에 매우 집중합니다. 카페인과 같이 자주 사용하는 데이터(핫키)를 인애플리케이션 캐시에 저장하는 것을 고려할 수 있나요? 🎜🎜인앱 캐시에 정규화된 데이터가 있으면 네트워크를 통해 Redis에서 해당 데이터를 얻을 필요 없이 직접 사용할 수 있으므로 2레벨 캐시가 형성됩니다. 🎜🎜🎜인앱 캐시를 1차 캐시라고 하고, 원격 캐시(예: redis)를 2차 캐시🎜라고 합니다. 🎜🎜전체 과정은 다음과 같습니다🎜🎜🎜🎜과정은 매우 신선해 보이지만 사실 2단계 캐시에는 고려해야 할 점이 많습니다. 🎜🎜1.분산 노드의 1차 캐시 일관성을 어떻게 보장할 수 있나요? 🎜🎜첫 번째 수준 캐시는 애플리케이션 내 캐시라고 하는데, 프로젝트가 여러 노드에 배포될 때 특정 키를 수정하거나 삭제할 때 다른 노드가 작동하는지 확인하는 방법은 🎜🎜 어떻습니까? 수준 캐시 일관성? 🎜🎜2. 는 null 값을 저장할 수 있나요? 🎜🎜이 점은 정말 고려해야 할 점입니다. 특정 쿼리가 캐시나 데이터베이스에 없으면 데이터베이스 쿼리가 자주 발생하여 데이터베이스가 다운되는 현상을 흔히 캐시 침투라고 합니다. 🎜🎜하지만 null 값을 저장하게 되면 많은 null 값이 저장되어 캐시가 커지는 경우가 있으므로 이를 구성 가능하게 하고 업종에 따라 활성화 여부를 결정하는 것이 가장 좋습니다. 🎜🎜3.캐시 예열이 필요한가요? 🎜也就是说，我们会觉得某些key一开始就会非常的热，也就是热点数据，那么我们是否可以一开始就先存储到缓存中，避免缓存击穿。
4.一级缓存存储数量上限的考虑？
既然一级缓存是应用内缓存，那你是否考虑一级缓存存储的数据给个限定最大值，避免存储太多的一级缓存导致OOM。
5.一级缓存过期策略的考虑？
我们说redis作为二级缓存，redis是淘汰策略来管理的。具体可参考redis的8种淘汰策略。那你的一级缓存策略呢？就好比你设置一级缓存
数量最大为5000个,那当第5001个进来的时候，你是怎么处理呢？是直接不保存，还是说自定义LRU或者LFU算法去淘汰之前的数据？
6.一级缓存过期了如何清除？
我们说redis作为二级缓存，我们有它的缓存过期策略(定时、定期、惰性)，那你的一级缓存呢，过期如何清除呢？
这里4、5、6小点如果说用我们传统的Map显然实现是很费劲的，但现在有更好用的一级缓存库那就是Caffeine。
Caffeine，一个用于Java的高性能缓存库。
缓存和Map之间的一个根本区别是缓存会清理存储的项目。
Caffeine有三种缓存写入策略：手动、同步加载和异步加载。
Caffeine有三种缓存值的清理策略：基于大小、基于时间和基于引用。
基于容量：当缓存大小超过配置的大小限制时会发生回收。
基于时间：
写入后到期策略。
访问后过期策略。
到期时间由 Expiry 实现独自计算。
基于引用：启用基于缓存键值的垃圾回收。
Caffeine可以将值封装为弱引用或软引用，并且Java中还有强引用和虚引用这两种引用类型。
软引用：如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。
弱引用：在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会
回收它的内存。
Caffeine提供了一种记录缓存使用统计信息的方法，可以实时监控缓存当前的状态，以评估缓存的健康程度以及缓存命中率等，方便后
续调整参数。
缓存淘汰算法的目的是利用有限的资源，尽量预测哪些数据将会在短期内被频繁使用，以此来提高缓存的命中率。常用的缓存淘汰算法有
LRU、LFU、FIFO等。
FIFO：先进先出。选择最先进入的数据优先淘汰。 LRU：最近最少使用。选择最近最少使用的数据优先淘汰。 LFU：最不经常使用。选择在一段时间内被使用次数最少的数据优先淘汰。
LRU（Least Recently Used）算法认为最近访问过的数据将来被访问的几率也更高。
LRU通常使用链表来实现，如果数据添加或者被访问到则把数据移动到链表的头部，链表的头部为热数据，链表的尾部如冷数据，当
数据满时，淘汰尾部的数据。
LFU（Least Frequently Used）算法根据数据的历史访问频率来淘汰数据，其核心思想是“如果数据过去被访问多次，那么将来被访问
的频率也更高”。根据LFU的思想，如果想要实现这个算法，需要额外的一套存储用来存每个元素的访问次数，会造成内存资源的浪费。
Caffeine采用了一种结合LRU、LFU优点的算法：W-TinyLFU，其特点：高命中率、低内存占用。
底层数据存储使用了ConcurrentHashMap。因为Caffeine面向JDK8，在jdk8中ConcurrentHashMap增加了红黑树，在hash冲突
严重时也能有良好的读性能。
前面说了，使用了redis缓存，也会存在一定程度的网络传输上的消耗，所以会考虑应用内缓存，但有点很重要的要记住:
应用内缓存可以理解成比redis缓存更珍惜的资源，所以，caffeine 不适用于数据量大，并且缓存命中率极低的业务场景，如用户维度的缓存。
当前项目针对应用都部署了多个节点，一级缓存是在应用内的缓存，所以当对数据更新和清除时，需要通知所有节点进行清理缓存的操作。
可以有多种方式来实现这种效果，比如：zookeeper、MQ等，但是既然用了redis缓存，redis本身是有支持订阅/发布功能的，所以就
不依赖其他组件了，直接使用redis的通道来通知其他节点进行清理缓存的操作。
只需通过发布订阅机制通知其他节点删除该key在本地一级缓存中的条目，即可在key更新或删除操作后实现同步。
具体具体项目代码这里就不再粘贴出来了，这样只粘贴如何引用这个starter包。
<dependency>
<groupId>com.jincou</groupId>
<artifactId>redis-caffeine-cache-starter</artifactId>
<version>1.0.0</version>
</dependency>添加二级缓存相关配置
# 二级缓存配置
# 注：caffeine 不适用于数据量大，并且缓存命中率极低的业务场景，如用户维度的缓存。请慎重选择。
l2cache:
config:
# 是否存储空值，默认true，防止缓存穿透
allowNullValues: true
# 组合缓存配置
composite:
# 是否全部启用一级缓存，默认false
l1AllOpen: false
# 是否手动启用一级缓存，默认false
l1Manual: true
# 手动配置走一级缓存的缓存key集合，针对单个key维度
l1ManualKeySet:
- userCache:user01
- userCache:user02
- userCache:user03
# 手动配置走一级缓存的缓存名字集合，针对cacheName维度
l1ManualCacheNameSet:
- userCache
- goodsCache
# 一级缓存
caffeine:
# 是否自动刷新过期缓存 true 是 false 否
autoRefreshExpireCache: false
# 缓存刷新调度线程池的大小
refreshPoolSize: 2
# 缓存刷新的频率(秒)
refreshPeriod: 10
# 写入后过期时间(秒)
expireAfterWrite: 180
# 访问后过期时间(秒)
expireAfterAccess: 180
# 初始化大小
initialCapacity: 1000
# 最大缓存对象个数，超过此数量时之前放入的缓存将失效
maximumSize: 3000
# 二级缓存
redis:
# 全局过期时间，单位毫秒，默认不过期
defaultExpiration: 300000
# 每个cacheName的过期时间，单位毫秒，优先级比defaultExpiration高
expires: {userCache: 300000,goodsCache: 50000}
# 缓存更新时通知其他节点的topic名称 默认 cache:redis:caffeine:topic
topic: cache:redis:caffeine:topic/**
* 启动类
*/
@EnableCaching
@SpringBootApplication
public class CacheApplication {
public static void main(String[] args) {
SpringApplication.run(CacheApplication.class, args);
}
}/**
* 测试
*/
@Service
public class CaffeineCacheService {
private final Logger logger = LoggerFactory.getLogger(CaffeineCacheService.class);
/**
* 用于模拟db
*/
private static Map<String, UserDTO> userMap = new HashMap<>();
{
userMap.put("user01", new UserDTO("1", "张三"));
userMap.put("user02", new UserDTO("2", "李四"));
userMap.put("user03", new UserDTO("3", "王五"));
userMap.put("user04", new UserDTO("4", "赵六"));
}
/**
* 获取或加载缓存项
*/
@Cacheable(key = "'cache_user_id_' + #userId", value = "userCache")
public UserDTO queryUser(String userId) {
UserDTO userDTO = userMap.get(userId);
try {
Thread.sleep(1000);// 模拟加载数据的耗时
} catch (InterruptedException e) {
e.printStackTrace();
}
logger.info("加载数据:{}", userDTO);
return userDTO;
}
/**
* 获取或加载缓存项
* <p>
* 注：因底层是基于caffeine来实现一级缓存，所以利用的caffeine本身的同步机制来实现
* sync=true 则表示并发场景下同步加载缓存项，
* sync=true，是通过get(Object key, Callable<T> valueLoader)来获取或加载缓存项，此时valueLoader（加载缓存项的具体逻辑）会被缓存起来，所以CaffeineCache在定时刷新过期缓存时，缓存项过期则会重新加载。
* sync=false，是通过get(Object key)来获取缓存项，由于没有valueLoader（加载缓存项的具体逻辑），所以CaffeineCache在定时刷新过期缓存时，缓存项过期则会被淘汰。
* <p>
*/
@Cacheable(value = "userCache", key = "#userId", sync = true)
public List<UserDTO> queryUserSyncList(String userId) {
UserDTO userDTO = userMap.get(userId);
List<UserDTO> list = new ArrayList();
list.add(userDTO);
logger.info("加载数据:{}", list);
return list;
}
/**
* 更新缓存
*/
@CachePut(value = "userCache", key = "#userId")
public UserDTO putUser(String userId, UserDTO userDTO) {
return userDTO;
}
/**
* 淘汰缓存
*/
@CacheEvict(value = "userCache", key = "#userId")
public String evictUserSync(String userId) {
return userId;
}
}위 내용은 Spring Cache 기반 Caffeine+Redis 2차 캐시 구현 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
