这对缓存 CP 直接炸场！Redis+Caffeine 强强联手有多狠？

2025-10-11

兄弟们，今天咱来唠唠缓存界的 "神雕侠侣"——Redis 和 Caffeine。这俩货要是组起 CP 来，那性能简直能让你的系统原地起飞。先别急着问原理，咱先从程序员的日常痛点说起：有没有试过凌晨三点被监控报警吵醒，发现是缓存雪崩把数据库搞挂了？有没有遇到过热点数据把 Redis 压得喘不过气，网络延迟比你摸鱼时的网速还慢？别慌，这对 CP 就是来救场的。

一、为啥非得组 CP？单飞不香吗？

先说说 Redis 这位老大哥，作为分布式缓存的扛把子，它就像一个超大的仓库，能存海量数据，还支持各种复杂操作。但仓库嘛，毕竟离你的工位有点远（网络延迟），每次取东西都得跑一趟，要是赶上仓库管理员忙（高并发），还得排队。再看 Caffeine，这就是你桌上的抽屉，存的都是你最近常用的东西，伸手就能够到，速度那叫一个快。但抽屉容量有限，装不了太多东西，而且要是停电了（进程重启），里面的东西就没了。

1. Redis 的烦恼：远水解不了近渴

网络延迟：哪怕是 1ms 的延迟，在百万级并发下也能积少成多，就像你每天多花 1 分钟找东西，一年下来能少写多少代码？带宽压力：每次从 Redis 取大对象，带宽就像被堵在晚高峰的马路，尤其是热点数据，能把带宽吃到撑。集群瓶颈：Redis 集群虽然能扩容，但分片键要是没设计好，就像把东西乱堆在仓库，找起来更麻烦。

2. Caffeine 的无奈：抽屉虽快但太小

容量限制：再大的抽屉也装不下整个仓库的东西，存太多就会被挤出去（淘汰策略）。数据不一致：本地缓存和远程缓存的数据要是没同步好，就像你记了两套账，迟早得出问题。进程隔离：每个服务实例都有自己的抽屉，数据不能共享，就像团队成员各自藏私货，协作起来费劲。

3. 最佳拍档：冷热数据分层

就像食堂打饭，常用的菜（热数据）放在窗口附近，不常用的（冷数据）放在仓库。Caffeine 负责存最热的数据，让你秒取；Redis 作为二级缓存，存次热的数据；数据库作为保底。这样一来，大部分请求都能在本地解决，少部分去 Redis，极少部分才去数据库，系统压力直接砍半。

二、CP 合体指南：从牵手到洞房的全过程

1. 基础架构：两层缓存怎么搭？

复制

// 伪代码示意 public Object get(String key) { // 先查本地缓存，就像先翻抽屉 Object value = caffeineCache.get(key); if (value != null) { return value; } // 抽屉没有再查Redis，就像去仓库找 value = redisTemplate.get(key); if (value != null) { // 把仓库的东西放进抽屉，下次直接拿 caffeineCache.put(key, value); } else { // 仓库也没有，就得去数据库搬了 value = database.query(key); if (value != null) { redisTemplate.set(key, value); caffeineCache.put(key, value); } } return value; }1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.

这里有个小细节：从 Redis 拿到数据后，要不要立即更新 Caffeine？要看你的数据更新频率。如果是读多写少，比如商品详情页，没问题；如果是写频繁，比如订单状态，就得考虑更新策略了。

2. 数据同步：如何避免 "抽屉" 和 "仓库" 闹别扭？

（1）失效模式（Cache-Aside）读：先查 Caffeine，没有查 Redis，再没有查数据库，然后更新两级缓存。写：先更新数据库，再删除 Caffeine 和 Redis 的缓存。注意，这里删除顺序很重要，要是先删 Redis，可能会有并发问题，导致脏数据。（2）异步更新（Write-Behind）

适合对数据一致性要求不高的场景，比如日志记录。写操作先把数据扔进队列，后台异步更新两级缓存。但风险也不小，要是服务挂了，队列里的数据就没了，得配合持久化队列使用。

（3）订阅发布（Pub/Sub）

利用 Redis 的发布订阅功能，当数据更新时，发布一个事件，所有订阅的服务实例收到事件后，删除本地缓存。就像班长通知全班交作业，每个人收到通知后把自己的旧作业删掉，下次重新拿新的。

3. 淘汰策略：抽屉满了该扔谁？

Caffeine 支持三种淘汰策略，就像收拾抽屉时决定先扔哪个旧东西：

LRU（最近最少使用）：很久没用过的东西，先扔掉，比如你去年用过一次的计算器。LFU（最不常用）：用得少的东西，先扔掉，比如你抽屉里积灰的 U 盘。TTL（生存时间）：不管用没用，到期就扔，比如过期的零食。

实际使用中，推荐 LRU+TTL 组合，比如热点数据设置较长的 TTL，普通数据用 LRU 淘汰。Redis 这边也可以配置淘汰策略，比如 allkeys-lru，和 Caffeine 形成互补。

4. 性能优化：这些细节能让速度再提 20%

序列化方式：Caffeine 存的是 Java 对象，直接存内存，不需要序列化；Redis 存的是字节数组，推荐用 Protostuff 或 Kryo 替代默认的 JDK 序列化，体积更小，速度更快。并发控制：Caffeine 本身是线程安全的，底层用了 Java 8 的 ConcurrentHashMap 结构；Redis 操作需要考虑分布式锁，比如用 Redisson 的分布式可重入锁，避免多个实例同时更新缓存。预热机制：启动时提前加载热点数据到 Caffeine，就像早上提前把常用工具放进抽屉，避免第一个请求进来时冷启动。

三、实战踩坑指南：这几个坑差点让我丢了饭碗

1. 缓存穿透：黑客拿不存在的 key 疯狂攻击

场景：用户用一个不存在的商品 ID 疯狂请求，每次都得查数据库，就像有人天天敲你家门问 "有人吗"，但其实没人住。

解决方案：

布隆过滤器：在入口处加一个过滤器，先判断 key 是否存在，不存在直接返回。就像在门口装个猫眼，先看看是不是熟人。空值缓存：查数据库后，即使没数据，也在两级缓存存一个空值，设置短 TTL，比如 5 分钟。

2. 缓存雪崩：大面积缓存同时失效

场景：凌晨三点，大量缓存同时过期，请求像潮水一样涌到数据库，就像全班同学同时找老师问问题，老师直接忙晕。

解决方案：

随机 TTL：给缓存过期时间加一个随机值，比如 10-15 分钟，避免集中失效。本地锁：当缓存失效时，用 synchronized 先锁住本地线程，只让一个线程去更新缓存，其他线程等待。注意，这只能解决单个实例的问题，分布式场景得用 Redis 分布式锁。

3. 数据倾斜：热点数据把 Caffeine 撑爆

场景：双 11 时，某个爆款商品的访问量是其他商品的 100 倍，Caffeine 里全是这个商品的数据，其他数据被挤出去了。

解决方案：

分片处理：把热点数据拆分成多个 key，比如 "product:123:1"、"product:123:2"，分散到不同的 Caffeine 实例中。二级缓存限流：给 Caffeine 设置最大容量，超过后按淘汰策略删除，同时记录热点数据，动态调整容量。

4. 一致性难题：先更新数据库还是先删缓存？

这是个经典问题，没有绝对正确的答案，得看具体场景：

读多写少：先更新数据库，再删缓存。如果先删缓存，此时有读请求进来，会从数据库查旧数据并更新缓存，导致脏数据。但先更新数据库后删缓存，如果删缓存失败，下次读会读到旧数据，不过可以通过异步任务补偿。写多读少：直接更新数据库，不维护缓存，读的时候再重新加载。比如后台管理系统，写操作多，读操作少，没必要维护缓存。

四、性能测试：这数据看得我热血沸腾

为了验证这对 CP 的威力，我做了一组性能测试，环境如下：

服务器：4 核 8G，带宽 1Gbps客户端：JMeter，1000 并发，10 万次请求数据：1KB 的字符串，热点数据占比 20%

1. 单 Redis vs 双缓存对比

指标

单 Redis

Redis+Caffeine

提升比例

平均响应时间

12ms

2ms

83.3%

吞吐量

8000req/s

45000req/s

462.5%

数据库压力

高

极低

可以看到，加上 Caffeine 后，响应时间直接降到原来的 1/6，吞吐量翻了 4 倍多，数据库基本没压力了。这就是本地缓存的威力，把大部分请求都在内存里解决了。

2. 不同淘汰策略对比

策略

缓存命中率

内存占用

复杂度

LRU

85%

中

低

LFU

88%

高

中

TTL+LRU

92%

低

高

实测发现，TTL+LRU 组合命中率最高，因为既考虑了数据的使用频率，又避免了长期不用的数据占用空间。不过复杂度也更高，需要合理设置 TTL 和容量。

五、最佳实践：这几个配置让你的 CP 更稳

1. Caffeine 配置模板

复制

Caffeine.newBuilder() .maximumSize(10_000) // 最大容量，根据内存大小调整，一般不超过可用内存的1/4 .expireAfterAccess(10, TimeUnit.MINUTES) // 最后一次访问后10分钟过期 .expireAfterWrite(5, TimeUnit.MINUTES) // 写入后5分钟过期，二者取早 .initialCapacity(2_000) // 初始容量，避免频繁扩容 .concurrencyLevel(Runtime.getRuntime().availableProcessors()) // 并发级别，等于CPU核心数 .recordStats() // 开启统计，方便监控命中率、淘汰次数等 .build();1.2.3.4.5.6.7.8.

2. Redis 配置关键点

连接池：使用 Jedis 或 Lettuce，推荐 Lettuce，支持异步 IO，高并发下表现更好。序列化：配置 spring.redis.serializer 为 GenericJackson2JsonRedisSerializer，比默认的 JDK 序列化更高效。监控：定期查看 info stats 里的 keyspace 命中情况，比如 keyspace_hits/keyspace_misses，命中率低于 90% 就要考虑优化了。