1.1 传统缓存方案#

传统查询链路通常是：

这种方案虽然已经通过 Redis 减少了数据库访问，但仍然存在两个突出问题：

1. 所有动态请求都必须经过 Tomcat
   当并发持续升高时，Tomcat 的线程、CPU、连接池等资源可能成为系统瓶颈。

2. Redis 未命中会把压力继续传给数据库
   缓存过期、冷启动或热点 Key 失效时，大量请求可能同时访问数据库。

1.2 多级缓存方案#

多级缓存会充分利用请求链路中的各层存储能力：

典型查询顺序如下：

1. 浏览器访问静态资源时，优先读取浏览器缓存；
2. 动态请求到达 Nginx 后，优先查询 Nginx 本地缓存；
3. Nginx 本地缓存未命中时，查询 Redis；
4. Redis 未命中时，请求 Tomcat；
5. Tomcat 优先查询 JVM 进程缓存；
6. JVM 进程缓存未命中时，最后查询数据库。

这样可以逐层拦截请求，减少对后端服务和数据库的访问。

1.3 各层缓存的职责#

在课程架构中，承担业务查询和缓存逻辑的 Nginx 已不只是反向代理服务器，而是一个可通过 OpenResty 与 Lua 编写业务逻辑的 Web 服务。因此通常会把它部署成集群，并在前面再设置专门的反向代理 Nginx。

2.1 什么是进程缓存#

JVM 进程缓存是保存在当前 Java 进程堆内存中的数据。常见实现包括：

• HashMap；
• ConcurrentHashMap；
• Guava Cache；
• Caffeine。

与普通 Map 相比，专业缓存库通常还提供：

• 最大容量控制；
• 基于时间的过期；
• 自动加载；
• 并发访问控制；
• 驱逐策略；
• 命中率、加载耗时等统计；
• 移除监听、异步刷新等扩展能力。

2.2 进程缓存与 Redis 的区别#

二者不是互相替代的关系。常见做法是把 Caffeine 作为一级缓存（L1），把 Redis 作为二级缓存（L2）。

2.3 进程缓存的边界#

使用 JVM 进程缓存时要明确：

• 每个 Tomcat 实例都有自己的缓存副本；
• 请求被负载均衡到不同实例时，可能连续发生多次未命中；
• 实例扩容后，新实例的缓存是空的；
• 应用重启后，缓存会全部丢失；
• 数据更新后，需要考虑所有实例中旧值的失效问题；
• 缓存对象会占用 JVM 堆，容量失控可能增加 GC 压力，甚至导致 OOM。

因此，进程缓存适合保存“体积较小、访问频繁、可重新加载”的数据，不应充当可靠的最终数据源。

3.1 Caffeine 的定位#

Caffeine 是 Java 平台上的高性能本地缓存库，提供手动缓存、同步加载缓存和异步缓存等模式。

Spring Framework 提供了对 Caffeine 的适配，可以通过 CaffeineCache、CaffeineCacheManager 或 Spring Cache 注解使用它。需要注意：Spring 的缓存模块是一层抽象，Caffeine 是它支持的具体缓存实现之一，不能简单理解为“Spring 内部默认缓存就是 Caffeine”。

官方资料：

• Caffeine GitHub
• Caffeine Population：缓存加载方式
• Caffeine Eviction：驱逐策略
• Spring Framework CaffeineCache API

1
<dependency>
2
    <groupId>com.github.ben-manes.caffeine</groupId>
3
    <artifactId>caffeine</artifactId>
4
</dependency>

3.2 基本 API#

1
@Test
2
void testBasicOps() {
3
    // 1. 创建手动缓存。未配置过期或容量时，缓存可能持续增长。
4
    Cache<String, String> cache = Caffeine.newBuilder()
5
            .maximumSize(100)
6
            .build();
7

8
    // 2. 写入或覆盖
9
    cache.put("name", "Caffeine");
10

11
    // 3. 只查询缓存；未命中返回 null
12
    String value = cache.getIfPresent("name");
13

14
    // 4. 查询缓存；未命中时执行加载函数，并把非 null 结果写入缓存
15
    String loaded = cache.get("language", key -> {
16
        // 实际业务中可以在这里查询数据库或调用下一级缓存
17
        return "Java";
18
    });
19

20
    // 5. 删除单个 Key
21
    cache.invalidate("name");
22

23
    // 6. 清空缓存
24
    cache.invalidateAll();
25
}

常用方法：

同一个测试类的容量驱逐案例使用 Thread.sleep(10L) 等待维护任务，这会让测试依赖机器调度。需要稳定断言时，可在写入后调用 cache.cleanUp() 触发待执行的维护，再检查条目或统计信息。

3.3 为什么优先使用 cache.get#

不要把“先判断，再加载，再写入”拆成三个独立步骤：

1
// 不推荐：并发请求可能同时发现缓存未命中，然后重复查询数据库
2
Item item = cache.getIfPresent(id);
3
if (item == null) {
4
    item = itemService.getById(id);
5
    cache.put(id, item);
6
}
7
return item;

更推荐：

1
return cache.get(id, itemService::getById);

cache.get(key, mappingFunction) 会以原子方式完成“未命中时计算并写入”。同一个 JVM 内并发访问同一 Key 时，它能减少重复加载，缓解本机范围内的缓存击穿。

但它只能协调当前进程中的线程，不能阻止其他 Tomcat 实例同时回源。如果需要跨实例控制热点 Key 的并发回源，还需要 Redis 锁、逻辑过期、请求合并等分布式方案。

3.4 空值与异常#

加载函数可能查询不到数据，也可能抛出异常：

1
Item item = itemCache.get(id, key -> itemService.getById(key));

需要注意：

• 加载函数返回 null 时，不会形成一个正常的 Caffeine 缓存条目；
• 如果热点请求持续查询一个不存在的 ID，仍可能反复访问数据库，这就是缓存穿透；
• 加载函数抛出异常时，异常会向调用方传播，不应把系统错误当作正常数据缓存；
• 可以缓存一个明确的空对象或包装类型，并设置较短有效期，但不能直接把“数据不存在”和“查询失败”混为一谈。

例如：

1
record CacheValue<T>(boolean found, T data) {
2
    static <T> CacheValue<T> hit(T data) {
3
        return new CacheValue<>(true, data);
4
    }
5

6
    static <T> CacheValue<T> notFound() {
7
        return new CacheValue<>(false, null);
8
    }
9
}

4.1 基于容量#

1
Cache<Long, Item> cache = Caffeine.newBuilder()
2
        .initialCapacity(100)
3
        .maximumSize(10_000)
4
        .build();

• initialCapacity(100)：初始容量提示，用于减少早期扩容，不是最小容量，也不是上限；
• maximumSize(10_000)：最多保留约 10,000 个条目；
• 达到上限后，Caffeine 会根据访问频率与近期访问情况选择条目驱逐；
• maximumSize 限制的是条目数量，不是内存字节数。

如果不同条目的内存大小差异很大，可以考虑 maximumWeight 与 weigher：

1
Cache<Long, byte[]> cache = Caffeine.newBuilder()
2
        .maximumWeight(10 * 1024 * 1024)
3
        .weigher((Long key, byte[] value) -> value.length)
4
        .build();

这里的权重由业务定义，不等同于 JVM 对象的精确内存占用。

4.2 基于时间#

1
Cache<Long, Item> cache = Caffeine.newBuilder()
2
        .expireAfterWrite(Duration.ofMinutes(10))
3
        .maximumSize(10_000)
4
        .build();

1
Cache<Long, Item> cache = Caffeine.newBuilder()
2
        .expireAfterAccess(Duration.ofMinutes(10))
3
        .maximumSize(10_000)
4
        .build();

4.3 基于引用#

Caffeine 支持弱引用 Key、弱引用 Value 和软引用 Value，但这类策略依赖 GC，回收时间和容量都不够可预测。通常更推荐使用明确的 maximumSize 或 maximumWeight。

4.4 过期不等于立即删除#

默认情况下，条目到达过期时间后，不一定会在那个时间点被后台线程立即物理删除。清理通常在写操作、部分读操作或维护任务中完成。

因此应这样理解：

• 过期条目不会再作为有效命中返回；
• estimatedSize() 在维护完成前可能仍包含等待清理的条目；
• 不要用缓存内部条目是否已物理删除，替代业务上的过期判断。

如果业务要求更及时地执行过期维护，可按所用 Java 与 Caffeine 版本评估 scheduler 配置。

4.5 刷新与过期的区别#

refreshAfterWrite 和 expireAfterWrite 语义不同：

• 过期：旧值失效，后续请求通常要等待新值加载；
• 刷新：条目达到刷新条件后，在被访问时异步加载新值，刷新期间仍可返回旧值。

刷新适合允许短时间旧数据、但希望降低重新加载等待时间的场景。它通常用于 LoadingCache，并需要谨慎设计加载线程池、失败回退和数据一致性。

5.1 需求#

给商品服务增加两组 JVM 进程缓存：

• 根据 ID 查询商品，未命中时查询数据库；
• 根据 ID 查询库存，未命中时查询数据库；
• 初始容量为 100；
• 最大条目数为 10,000。

商品与库存应使用不同缓存，原因包括：

• 数据类型不同；
• 更新频率不同；
• 过期时间可能不同；
• 需要分别统计命中率和执行失效操作。

5.2 定义缓存 Bean#

1
@Configuration
2
public class CaffeineConfig {
3

4
    @Bean
5
    public Cache<Long, Item> itemCache() {
6
        return Caffeine.newBuilder()
7
                .initialCapacity(100)
8
                .maximumSize(10_000)
9
                .build();
10
    }
11

12
    @Bean
13
    public Cache<Long, ItemStock> stockCache() {
14
        return Caffeine.newBuilder()
15
                .initialCapacity(100)
16
                .maximumSize(10_000)
17
                .build();
18
    }
19
}

上面是符合需求的最小实现。生产环境通常还应评估：

• 是否配置过期时间；
• 商品和库存是否采用不同有效期；
• 是否需要 recordStats()；
• 是否添加 removalListener；
• 最大条目数是否适合对象体积和 JVM 堆大小。

例如：

1
@Bean
2
public Cache<Long, Item> itemCache() {
3
    return Caffeine.newBuilder()
4
            .initialCapacity(100)
5
            .maximumSize(10_000)
6
            .expireAfterWrite(Duration.ofMinutes(10))
7
            .recordStats()
8
            .build();
9
}

5.3 在 Controller 中查询缓存#

1
@RestController
2
@RequestMapping("item")
3
public class ItemController {
4

5
    private final IItemService itemService;
6
    private final IItemStockService stockService;
7
    private final Cache<Long, Item> itemCache;
8
    private final Cache<Long, ItemStock> stockCache;
9

10
    public ItemController(
11
            IItemService itemService,
12
            IItemStockService stockService,
13
            Cache<Long, Item> itemCache,
14
            Cache<Long, ItemStock> stockCache) {
15
        this.itemService = itemService;
16
        this.stockService = stockService;
17
        this.itemCache = itemCache;
18
        this.stockCache = stockCache;
19
    }
20

21
    @GetMapping("/{id}")
22
    public Item findById(@PathVariable Long id) {
23
        return itemCache.get(id, key -> itemService.query()
24
                .ne("status", 3)
25
                .eq("id", key)
26
                .one());
27
    }
28

29
    @GetMapping("/stock/{id}")
30
    public ItemStock findStockById(@PathVariable Long id) {
31
        return stockCache.get(id, stockService::getById);
32
    }
33
}

这里改用构造器注入，依赖关系更明确，也更方便测试。

5.4 查询流程#

第一次请求某个 ID 时：

1. Caffeine 未命中；
2. 执行加载函数；
3. 查询数据库；
4. 将非空结果写入当前 JVM 的缓存；
5. 返回结果。

后续请求命中同一 Tomcat 实例时，可以直接从内存返回。

5.5 Tomcat 集群中的命中率#

课程后续会启动两个 Tomcat 实例，例如 8081 和 8082。如果 OpenResty 对它们使用轮询：

1
第一次查询 /item/10001 → 8081，建立 8081 的本地缓存
2
第二次查询 /item/10001 → 8082，8082 仍需查询数据库
3
第三次查询 /item/10001 → 8081，命中

因此课程使用请求 URI 做哈希，让同一商品尽量落到同一实例：

1
upstream tomcat-cluster {
2
    hash $request_uri;
3
    server 192.168.150.1:8081;
4
    server 192.168.150.1:8082;
5
}
6

7
location /item {
8
    proxy_pass http://tomcat-cluster;
9
}

其目标是提高 JVM 进程缓存命中率：

但需要区分两个问题：

• 固定路由解决的是命中率问题；
• 缓存同步解决的是数据一致性问题。

哈希路由不会让两个 JVM 共享缓存，也不会自动删除其他实例中的旧值。Tomcat 节点数量变化时，映射还可能重新分布，新节点仍会经历冷缓存。

6.1 常用处理策略#

当前服务是单实例时，可以在数据库更新成功后删除对应 Key：

1
public void updateItem(Item item) {
2
    itemService.updateById(item);
3
    itemCache.invalidate(item.getId());
4
}

集群部署时，只删除当前实例的 Caffeine 缓存还不够。其他实例仍可能保留旧值，需要借助：

• Redis Pub/Sub；
• 消息队列；
• Canal 或数据库变更事件；
• 配置中心或专门的缓存失效通道；
• 较短 TTL 作为最终兜底。

6.2 商品与库存应区别对待#

库存更新通常比商品基本信息更频繁，对时效性要求也更高。因此可以考虑：

• 商品信息采用较长 TTL；
• 库存采用较短 TTL；
• 对库存变更主动发送失效通知；
• 对强一致性库存扣减，不把本地缓存值当作最终扣减依据。

6.3 Canal 同步实现#

采用 Canal 监听 MySQL binlog，再更新 Caffeine 与 Redis。核心逻辑如下：

1
@CanalTable("tb_item")
2
@Component
3
public class ItemHandler implements EntryHandler<Item> {
4

5
    @Autowired
6
    private RedisHandler redisHandler;
7
    @Autowired
8
    private Cache<Long, Item> itemCache;
9

10
    @Override
11
    public void insert(Item item) {
12
        itemCache.put(item.getId(), item);
13
        redisHandler.saveItem(item);
14
    }
15

16
    @Override
17
    public void update(Item before, Item after) {
18
        itemCache.put(after.getId(), after);
19
        redisHandler.saveItem(after);
20
    }
21

22
    @Override
23
    public void delete(Item item) {
24
        itemCache.invalidate(item.getId());
25
        redisHandler.deleteItemById(item.getId());
26
    }
27
}

对应配置位于完成版 application.yml：

1
canal:
2
  destination: aron
3
  server: 192.168.150.101:11111

处理链路是：

这种方案降低了业务写接口与缓存维护代码之间的耦合，但属于异步同步，数据库提交与缓存更新之间仍可能存在短暂时间窗。

7.1 开启统计#

1
Cache<Long, Item> itemCache = Caffeine.newBuilder()
2
        .maximumSize(10_000)
3
        .recordStats()
4
        .build();
5

6
System.out.println(itemCache.stats().hitRate());
7
System.out.println(itemCache.stats().evictionCount());
8
System.out.println(itemCache.stats().averageLoadPenalty());

建议重点观察：

• hitRate()：命中率；
• missRate()：未命中率；
• loadSuccessCount()：成功加载次数；
• loadFailureCount()：加载失败次数；
• averageLoadPenalty()：平均加载耗时；
• evictionCount()：容量等原因导致的驱逐次数。

命中率不是越高越好。如果为了命中率缓存大量低价值对象，导致堆占用和 GC 压力上升，整体性能反而可能下降。

7.2 基本验证步骤#

1. 启动商品服务；
2. 打开数据库 SQL 日志；
3. 第一次请求某商品 ID，确认执行了 SQL；
4. 再次请求相同 ID，确认不再执行 SQL；
5. 请求另一个 ID，确认会执行新的 SQL；
6. 使指定 Key 失效后再次请求，确认重新查询数据库；
7. 启动两个 Tomcat 实例，分别请求同一 ID，观察两个实例会各自建立缓存；
8. 修改数据库数据，验证失效策略是否能避免长期读取旧值。

7.3 示例单元测试#

1
@Test
2
void shouldLoadOnlyOnceForSameKey() {
3
    AtomicInteger loadCount = new AtomicInteger();
4

5
    Cache<Long, String> cache = Caffeine.newBuilder()
6
            .maximumSize(100)
7
            .build();
8

9
    String first = cache.get(1L, key -> {
10
        loadCount.incrementAndGet();
11
        return "item-1";
12
    });
13

14
    String second = cache.get(1L, key -> {
15
        loadCount.incrementAndGet();
16
        return "item-1-new";
17
    });
18

19
    assertEquals("item-1", first);
20
    assertEquals("item-1", second);
21
    assertEquals(1, loadCount.get());
22
}

测试时间过期时，优先使用 Caffeine 提供的可控时间源思路，而不是让测试线程真实等待数秒，这样测试会更快、更稳定。