在高性能的服务架构设计中，缓存是一个不可或缺的环节。在实际的项目中，我们通常会将一些热点数据存储到Redis或MemCache这类缓存中间件中，只有当缓存的访问没有命中时再查询数据库。在提升访问速度的同时，也能降低数据库的压力。
随着不断的发展，这一架构也产生了改进，在一些场景下可能单纯使用Redis类的远程缓存已经不够了，还需要进一步配合本地缓存使用，例如Guava cache或Caffeine，从而再次提升程序的响应速度与服务性能。于是，就产生了使用本地缓存作为一级缓存，再加上远程缓存作为二级缓存的两级缓存架构。
在先不考虑并发等复杂问题的情况下，两级缓存的访问流程可以用下面这张图来表示：
优点与问题
那么，使用两级缓存相比单纯使用远程缓存，具有什么优势呢？
- 本地缓存基于本地环境的内存，访问速度非常快，对于一些变更频率低、实时性要求低的数据，可以放在本地缓存中，提升访问速度
- 使用本地缓存能够减少和
Redis类的远程缓存间的数据交互，减少网络I/O开销，降低这一过程中在网络通信上的耗时
但是在设计中，还是要考虑一些问题的，例如数据一致性问题。首先，两级缓存与数据库的数据要保持一致，一旦数据发生了修改，在修改数据库的同时，本地缓存、远程缓存应该同步更新。
另外，如果是分布式环境下，一级缓存之间也会存在一致性问题，当一个节点下的本地缓存修改后，需要通知其他节点也刷新本地缓存中的数据，否则会出现读取到过期数据的情况，这一问题可以通过类似于Redis中的发布/订阅功能解决。
此外，缓存的过期时间、过期策略以及多线程访问的问题也都需要考虑进去，不过我们今天暂时先不考虑这些问题，先看一下如何简单高效的在代码中实现两级缓存的管理。
准备工作
在简单梳理了一下要面对的问题后，下面开始两级缓存的代码实战，我们整合号称最强本地缓存的Caffeine作为一级缓存、性能之王的Redis作为二级缓存。首先建一个springboot项目，引入缓存要用到的相关的依赖：
<dependency> <groupId>com.github.ben-manes.caffeine</groupId> <artifactId>caffeine</artifactId> <version>2.9.2</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-cache</artifactId> </dependency> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-pool2</artifactId> <version>2.8.1</version> </dependency>
在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和序列化方式。
下面我们在单机环境下，将按照对业务侵入性的不同程度，分三个版本来实现两级缓存的使用。
V1.0版本
我们可以通过手动操作Caffeine中的Cache对象来缓存数据，它是一个类似Map的数据结构，以key作为索引，value存储数据。在使用Cache前，需要先配置一下相关参数：
@Configuration public class CaffeineConfig { @Bean public Cache<String,Object> caffeineCache(){ return Caffeine.newBuilder() .initialCapacity(128) //初始大小 .maximumSize(1024) //最大数量 .expireAfterWrite(60, TimeUnit.SECONDS) //过期时间 .build(); } }
简单解释一下Cache相关的几个参数的意义：
- initialCapacity：初始缓存空大小
- maximumSize：缓存的最大数量，设置这个值可以避免出现内存溢出
- expireAfterWrite：指定缓存的过期时间，是最后一次写操作后的一个时间，这里
此外，缓存的过期策略也可以通过expireAfterAccess或refreshAfterWrite指定。
在创建完成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<Order>() .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<Order>() .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); }
简单的演示到此为止，可以看到上面这种使用缓存的方式，虽然看起来没什么大问题，但是对代码的入侵性比较强。在业务处理的过程中要由我们频繁的操作两级缓存，会给开发人员带来很大负担。那么，有什么方法能够简化这一过程呢？我们看看下一个版本。
