共计 9459 个字符,预计需要花费 24 分钟才能阅读完成。
导读 | 缓存的过期时间、过期策略以及多线程访问的问题也都需要考虑进去,不过我们今天暂时先不考虑这些问题,先看一下如何简单高效的在代码中实现两级缓存的管理。 |
在高性能的服务架构设计中,缓存是一个不可或缺的环节。在实际的项目中,我们通常会将一些热点数据存储到 Redis 或 MemCache 这类缓存中间件中,只有当缓存的访问没有命中时再查询数据库。在提升访问速度的同时,也能降低数据库的压力。
随着不断的发展,这一架构也产生了改进,在一些场景下可能单纯使用 Redis 类的远程缓存已经不够了,还需要进一步配合本地缓存使用,例如 Guava cache 或 Caffeine,从而再次提升程序的响应速度与服务性能。于是,就产生了使用本地缓存作为一级缓存,再加上远程缓存作为二级缓存的两级缓存架构。
在先不考虑并发等复杂问题的情况下,两级缓存的访问流程可以用下面这张图来表示:
那么,使用两级缓存相比单纯使用远程缓存,具有什么优势呢?
本地缓存基于本地环境的内存,访问速度非常快,对于一些变更频率低、实时性要求低的数据,可以放在本地缓存中,提升访问速度;
使用本地缓存能够减少和 Redis 类的远程缓存间的数据交互,减少网络 I / O 开销,降低这一过程中在网络通信上的耗时;
但是在设计中,还是要考虑一些问题的,例如数据一致性问题。首先,两级缓存与数据库的数据要保持一致,一旦数据发生了修改,在修改数据库的同时,本地缓存、远程缓存应该同步更新。
另外,如果是分布式环境下,一级缓存之间也会存在一致性问题,当一个节点下的本地缓存修改后,需要通知其他节点也刷新本地缓存中的数据,否则会出现读取到过期数据的情况,这一问题可以通过类似于 Redis 中的发布 / 订阅功能解决。
此外,缓存的过期时间、过期策略以及多线程访问的问题也都需要考虑进去,不过我们今天暂时先不考虑这些问题,先看一下如何简单高效的在代码中实现两级缓存的管理。
在简单梳理了一下要面对的问题后,下面开始两级缓存的代码实战,我们整合号称最强本地缓存的 Caffeine 作为一级缓存、性能之王的 Redis 作为二级缓存。首先建一个 springboot 项目,引入缓存要用到的相关的依赖:
com.github.ben-manes.caffeine
caffeine
2.9.2
org.springframework.boot
spring-boot-starter-data-redis
org.springframework.boot
spring-boot-starter-cache
org.apache.commons
commons-pool2
2.8.1
在 application.yml 中配置 Redis 的连接信息:
spring:
redis:
host: 127.0.0.1
port: 6379
database: 0
timeout: 10000ms
lettuce:
pool:
max-active: 8
max-wait: -1ms
max-idle: 8
min-idle: 0
在下面的例子中,我们将使用 RedisTemplate 来对 redis 进行读写操作,RedisTemplate 使用前需要配置一下 ConnectionFactory 和序列化方式,这一过程比较简单就不贴出代码了。
下面我们在单机环境下,将按照对业务侵入性的不同程度,分三个版本来实现两级缓存的使用。
我们可以通过手动操作 Caffeine 中的 Cache 对象来缓存数据,它是一个类似 Map 的数据结构,以 key 作为索引,value 存储数据。在使用 Cache 前,需要先配置一下相关参数:
@Configuration
public class CaffeineConfig {
@Bean
public Cache caffeineCache(){return Caffeine.newBuilder()
.initialCapacity(128)// 初始大小
.maximumSize(1024)// 最大数量
.expireAfterWrite(60, TimeUnit.SECONDS)// 过期时间
.build();}
}
简单解释一下 Cache 相关的几个参数的意义:
initialCapacity:初始缓存空大小;
在创建完成 Cache 后,我们就可以在业务代码中注入并使用它了。在没有使用任何缓存前,一个只有简单的 Service 层代码是下面这样的,只有 crud 操作:
@Service
@AllArgsConstructor
public class OrderServiceImpl implements OrderService {
private final OrderMapper orderMapper;
@Override
public Order getOrderById(Long id) {Order order = orderMapper.selectOne(new LambdaQueryWrapper()
.eq(Order::getId, id));
return order;
}
@Override
public void updateOrder(Order order) {orderMapper.updateById(order);
}
@Override
public void deleteOrder(Long id) {orderMapper.deleteById(id);
}
}
接下来,对上面的 OrderService 进行改造,在执行正常业务外再加上操作两级缓存的代码,先看改造后的查询操作:
public Order getOrderById(Long id) {
String key = CacheConstant.ORDER + id;
Order order = (Order) cache.get(key,
k -> {
// 先查询 Redis
Object obj = redisTemplate.opsForValue().get(k);
if (Objects.nonNull(obj)) {log.info("get data from redis");
return obj;
}
// Redis 没有则查询 DB
log.info("get data from database");
Order myOrder = orderMapper.selectOne(new LambdaQueryWrapper()
.eq(Order::getId, id));
redisTemplate.opsForValue().set(k, myOrder, 120, TimeUnit.SECONDS);
return myOrder;
});
return order;
}
在 Cache 的 get 方法中,会先从缓存中进行查找,如果找到缓存的值那么直接返回。如果没有找到则执行后面的方法,并把结果加入到缓存中。
因此上面的逻辑就是先查找 Caffeine 中的缓存,没有的话查找 Redis,Redis 再不命中则查询数据库,写入 Redis 缓存的操作需要手动写入,而 Caffeine 的写入由 get 方法自己完成。
在上面的例子中,设置 Caffeine 的过期时间为 60 秒,而 Redis 的过期时间为 120 秒,下面进行测试,首先看第一次接口调用时,进行了数据库的查询:
而在之后 60 秒内访问接口时,都没有打印打任何 sql 或自定义的日志内容,说明接口没有查询 Redis 或数据库,直接从 Caffeine 中读取了缓存。
等到距离第一次调用接口进行缓存的 60 秒后,再次调用接口:
可以看到这时从 Redis 中读取了数据,因为这时 Caffeine 中的缓存已经过期了,但是 Redis 中的缓存没有过期仍然可用。
下面再来看一下修改操作,代码在原先的基础上添加了手动修改 Redis 和 Caffeine 缓存的逻辑:
public void updateOrder(Order order) {log.info("update order data");
String key=CacheConstant.ORDER + order.getId();
orderMapper.updateById(order);
// 修改 Redis
redisTemplate.opsForValue().set(key,order,120, TimeUnit.SECONDS);
// 修改本地缓存
cache.put(key,order);
}
看一下下面图中接口的调用、以及缓存的刷新过程。可以看到在更新数据后,同步刷新了缓存中的内容,再之后的访问接口时不查询数据库,也可以拿到正确的结果:
最后再来看一下删除操作,在删除数据的同时,手动移除 Reids 和 Caffeine 中的缓存:
public void deleteOrder(Long id) {log.info("delete order");
orderMapper.deleteById(id);
String key= CacheConstant.ORDER + id;
redisTemplate.delete(key);
cache.invalidate(key);
}
我们在删除某个缓存后,再次调用之前的查询接口时,又会出现重新查询数据库的情况:
简单的演示到此为止,可以看到上面这种使用缓存的方式,虽然看起来没什么大问题,但是对代码的入侵性比较强。在业务处理的过程中要由我们频繁的操作两级缓存,会给开发人员带来很大负担。那么,有什么方法能够简化这一过程呢? 我们看看下一个版本。
在 spring 项目中,提供了 CacheManager 接口和一些注解,允许让我们通过注解的方式来操作缓存。先来看一下常用几个注解说明:
@Cacheable:根据键从缓存中取值,如果缓存存在,那么获取缓存成功之后,直接返回这个缓存的结果。如果缓存不存在,那么执行方法,并将结果放入缓存中。
@CachePut:不管之前的键对应的缓存是否存在,都执行方法,并将结果强制放入缓存。
@CacheEvict:执行完方法后,会移除掉缓存中的数据。
如果要使用上面这几个注解管理缓存的话,我们就不需要配置 V1 版本中的那个类型为 Cache 的 Bean 了,而是需要配置 spring 中的 CacheManager 的相关参数,具体参数的配置和之前一样:
@Configuration
public class CacheManagerConfig {
@Bean
public CacheManager cacheManager(){CaffeineCacheManager cacheManager=new CaffeineCacheManager();
cacheManager.setCaffeine(Caffeine.newBuilder()
.initialCapacity(128)
.maximumSize(1024)
.expireAfterWrite(60, TimeUnit.SECONDS));
return cacheManager;
}
}
然后在启动类上再添加上 @EnableCaching 注解,就可以在项目中基于注解来使用 Caffeine 的缓存支持了。下面,再次对 Service 层代码进行改造。
首先,还是改造查询方法,在方法上添加 @Cacheable 注解:
@Cacheable(value = "order",key = "#id")
//@Cacheable(cacheNames = "order",key = "#p0")
public Order getOrderById(Long id) {
String key= CacheConstant.ORDER + id;
// 先查询 Redis
Object obj = redisTemplate.opsForValue().get(key);
if (Objects.nonNull(obj)){log.info("get data from redis");
return (Order) obj;
}
// Redis 没有则查询 DB
log.info("get data from database");
Order myOrder = orderMapper.selectOne(new LambdaQueryWrapper()
.eq(Order::getId, id));
redisTemplate.opsForValue().set(key,myOrder,120, TimeUnit.SECONDS);
return myOrder;
@Cacheable 注解的属性多达 9 个,好在我们日常使用时只需要配置两个常用的就可以了。其中 value 和 cacheNames 互为别名关系,表示当前方法的结果会被缓存在哪个 Cache 上,应用中通过 cacheName 来对 Cache 进行隔离,每个 cacheName 对应一个 Cache 实现。value 和 cacheNames 可以是一个数组,绑定多个 Cache。
而另一个重要属性 key,用来指定缓存方法的返回结果时对应的 key,这个属性支持使用 SpringEL 表达式。通常情况下,我们可以使用下面几种方式作为 key:
# 参数名
#参数对象. 属性名
#p 参数对应下标
在上面的代码中,我们看到添加了 @Cacheable 注解后,在代码中只需要保留原有的业务处理逻辑和操作 Redis 部分的代码即可,Caffeine 部分的缓存就交给 spring 处理了。
下面,我们再来改造一下更新方法,同样,使用 @CachePut 注解后移除掉手动更新 Cache 的操作:
@CachePut(cacheNames = "order",key = "#order.id")
public Order updateOrder(Order order) {log.info("update order data");
orderMapper.updateById(order);
// 修改 Redis
redisTemplate.opsForValue().set(CacheConstant.ORDER + order.getId(),
order, 120, TimeUnit.SECONDS);
return order;
}
注意,这里和 V1 版本的代码有一点区别,在之前的更新操作方法中,是没有返回值的 void 类型,但是这里需要修改返回值的类型,否则会缓存一个空对象到缓存中对应的 key 上。当下次执行查询操作时,会直接返回空对象给调用方,而不会执行方法中查询数据库或 Redis 的操作。
最后,删除方法的改造就很简单了,使用 @CacheEvict 注解,方法中只需要删除 Redis 中的缓存即可:
@CacheEvict(cacheNames = "order",key = "#id")
public void deleteOrder(Long id) {log.info("delete order");
orderMapper.deleteById(id);
redisTemplate.delete(CacheConstant.ORDER + id);
}
可以看到,借助 spring 中的 CacheManager 和 Cache 相关的注解,对 V1 版本的代码经过改进后,可以把全手动操作两级缓存的强入侵代码方式,改进为本地缓存交给 spring 管理,Redis 缓存手动修改的半入侵方式。那么,还能进一步改造,使之成为对业务代码完全无入侵的方式吗?
模仿 spring 通过注解管理缓存的方式,我们也可以选择自定义注解,然后在切面中处理缓存,从而将对业务代码的入侵降到最低。
首先定义一个注解,用于添加在需要操作缓存的方法上:
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface DoubleCache {String cacheName();
String key(); // 支持 springEl 表达式
long l2TimeOut() default 120;
CacheType type() default CacheType.FULL;}
我们使用 cacheName + key 作为缓存的真正 key(仅存在一个 Cache 中,不做 CacheName 隔离),l2TimeOut 为可以设置的二级缓存 Redis 的过期时间,type 是一个枚举类型的变量,表示操作缓存的类型,枚举类型定义如下:
public enum CacheType {
FULL, // 存取
PUT, // 只存
DELETE // 删除
}
因为要使 key 支持 springEl 表达式,所以需要写一个方法,使用表达式解析器解析参数:
public static String parse(String elString, TreeMap map){elString=String.format("#{%s}",elString);
// 创建表达式解析器
ExpressionParser parser = new SpelExpressionParser();
// 通过 evaluationContext.setVariable 可以在上下文中设定变量。EvaluationContext context = new StandardEvaluationContext();
map.entrySet().forEach(entry->
context.setVariable(entry.getKey(),entry.getValue())
);
// 解析表达式
Expression expression = parser.parseExpression(elString, new TemplateParserContext());
// 使用 Expression.getValue() 获取表达式的值,这里传入了 Evaluation 上下文
String value = expression.getValue(context, String.class);
return value;
}
参数中的 elString 对应的就是注解中 key 的值,map 是将原方法的参数封装后的结果。简单进行一下测试:
public void test() {
String elString="#order.money";
String elString2="#user";
String elString3="#p0";
TreeMap map=new TreeMap();
Order order = new Order();
order.setId(111L);
order.setMoney(123D);
map.put("order",order);
map.put("user","Hydra");
String val = parse(elString, map);
String val2 = parse(elString2, map);
String val3 = parse(elString3, map);
System.out.println(val);
System.out.println(val2);
System.out.println(val3);
}
执行结果如下,可以看到支持按照参数名称、参数对象的属性名称读取,但是不支持按照参数下标读取,暂时留个小坑以后再处理。
123.0
Hydra
null
至于 Cache 相关参数的配置,我们沿用 V1 版本中的配置即可。准备工作做完了,下面我们定义切面,在切面中操作 Cache 来读写 Caffeine 的缓存,操作 RedisTemplate 读写 Redis 缓存。
@Slf4j @Component @Aspect
@AllArgsConstructor
public class CacheAspect {
private final Cache cache;
private final RedisTemplate redisTemplate;
@Pointcut("@annotation(com.cn.dc.annotation.DoubleCache)")
public void cacheAspect() {}
@Around("cacheAspect()")
public Object doAround(ProceedingJoinPoint point) throws Throwable {MethodSignature signature = (MethodSignature) point.getSignature();
Method method = signature.getMethod();
// 拼接解析 springEl 表达式的 map
String[] paramNames = signature.getParameterNames();
Object[] args = point.getArgs();
TreeMap treeMap = new TreeMap();
for (int i = 0; i
切面中主要做了下面几件工作:
通过方法的参数,解析注解中 key 的 springEl 表达式,组装真正缓存的 key。
根据操作缓存的类型,分别处理存取、只存、删除缓存操作。
删除和强制更新缓存的操作,都需要执行原方法,并进行相应的缓存删除或更新操作。
存取操作前,先检查缓存中是否有数据,如果有则直接返回,没有则执行原方法,并将结果存入缓存。
修改 Service 层代码,代码中只保留原有业务代码,再添加上我们自定义的注解就可以了:
@DoubleCache(cacheName = "order", key = "#id",
type = CacheType.FULL)
public Order getOrderById(Long id) {Order myOrder = orderMapper.selectOne(new LambdaQueryWrapper()
.eq(Order::getId, id));
return myOrder;
}
@DoubleCache(cacheName = "order",key = "#order.id",
type = CacheType.PUT)
public Order updateOrder(Order order) {orderMapper.updateById(order);
return order;
}
@DoubleCache(cacheName = "order",key = "#id",
type = CacheType.DELETE)
public void deleteOrder(Long id) {orderMapper.deleteById(id);
}
到这里,基于切面操作缓存的改造就完成了,Service 的代码也瞬间清爽了很多,让我们可以继续专注于业务逻辑处理,而不用费心去操作两级缓存了。
总结本文按照对业务入侵的递减程度,依次介绍了三种管理两级缓存的方法。至于在项目中是否需要使用二级缓存,需要考虑自身业务情况,如果 Redis 这种远程缓存已经能够满足你的业务需求,那么就没有必要再使用本地缓存了。毕竟实际使用起来远没有那么简单,本文中只是介绍了最基础的使用,实际中的并发问题、事务的回滚问题都需要考虑,还需要思考什么数据适合放在一级缓存、什么数据适合放在二级缓存等等的其他问题。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)