深入多级缓存：JVM进程缓存实战与数据库表拆分策略

在高并发系统的架构设计中，多级缓存是提升性能的杀手锏。我们通常已经熟悉了Nginx层缓存和Redis分布式缓存，但作为最后一道防线的JVM进程缓存同样至关重要。

本文将聚焦于多级缓存架构中的“最后一道防线”——JVM进程缓存，并通过一个具体的商品查询案例，探讨如何通过数据库表拆分来优化缓存策略。

多级缓存架构回顾

在一个成熟的多级缓存体系中，请求的处理流程通常是层层递进的：

1. Nginx缓存：第一道关卡，拦截静态资源和热点数据。
2. Redis缓存：分布式共享层，承载大部分热点数据。
3. JVM进程缓存：位于Tomcat应用内部，利用本地内存（如Caffeine）进行极速读取。

当请求穿透了Nginx和Redis，到达Tomcat服务时，为了避免直接冲击数据库，我们需要在应用内部优先查询进程缓存。只有当进程缓存未命中时，才去查询数据库。

实战演练：商品查询案例

为了更好地理解这一机制，我们引入一个“商品详情浏览”的业务场景。

环境准备：MySQL容器化部署

在开始编码前，我们需要一个稳定的数据库环境。这里演示如何使用Docker快速部署MySQL 5.7.25。

首先，创建用于挂载数据和配置的目录，这对于后续修改配置和查看日志非常方便：

mkdir -p /tmp/mysql/conf mkdir -p /tmp/mysql/logs mkdir -p /tmp/mysql/data

接着，使用以下命令启动MySQL容器。请注意三个关键的数据卷挂载参数，它们保证了数据的持久化和配置的灵活性：

docker run \ -p 3306:3306 \ --name mysql \ -v $PWD/conf:/etc/mysql/conf.d \ -v $PWD/logs:/logs \ -v $PWD/data:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=123 \ --privileged \ -d \ mysql:5.7.25

为了优化性能，我们还需要自定义配置文件。在/tmp/mysql/conf目录下创建my.cnf文件，内容如下：

[mysqld] skip-name-resolve character_set_server=utf8 datadir=/var/lib/mysql server-id=1000

修改配置后，别忘了重启容器使其生效：

docker restart mysql

核心设计：数据库表拆分策略

在商品系统中，很多开发者习惯将所有商品信息（标题、价格、库存、详情描述）都放在一张tb_item表中。然而，在多级缓存架构下，这种设计存在隐患。

问题所在：
库存信息是更新极其频繁的数据（如秒杀场景），而商品标题、描述等基本信息则相对稳定。如果它们耦合在同一张表中，一旦库存更新导致缓存失效，原本稳定的商品详情也会被迫重新加载，这大大降低了缓存命中率。

优化方案：
我们将商品数据进行垂直拆分：

• tb_item（商品基本信息表）：存储ID、标题、价格、描述等低频修改数据。
• tb_item_stock（商品库存表）：存储ID、库存量、销量等高频修改数据。

设计考量：
通过这种分离，当库存发生变化时，我们只需要更新或失效库存表的缓存，而商品基本信息的缓存依然有效。这种细粒度的缓存控制，能显著降低数据库压力，提高整体系统的吞吐量。

总结与展望

本文介绍了多级缓存中JVM进程缓存的背景，并通过商品案例强调了数据库表设计对缓存效率的影响。

接下来的步骤，我们将基于这个拆分后的表结构，在Spring Boot项目中集成Caffeine，实现具体的JVM进程缓存逻辑，真正打通“Tomcat → 进程缓存 → 数据库”的查询链路。

知识点核心总结