兄弟们，今天咱来唠唠缓存界的 "神雕侠侣"——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;
}

这里有个小细节：从 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 双缓存对比

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

2. 不同淘汰策略对比

实测发现，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();

2. Redis 配置关键点

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

3. 监控报警体系

• 缓存命中率：低于 80% 时报警，可能是淘汰策略不合理或热点数据变化。
• 内存使用率：Caffeine 内存占用超过设定值的 80% 时报警，考虑扩容或调整容量。
• 更新失败率：数据同步失败次数超过一定阈值时报警，比如每分钟超过 10 次，可能是网络问题或数据库压力大。

六、哪些场景适合这对 CP？

1. 电商秒杀：热点商品的库存查询

秒杀时，热点商品的库存查询请求量极大，用 Caffeine 存最新的库存数据，Redis 存历史库存变化，既能保证速度，又能防止库存超卖。

2. 新闻 Feed：用户个性化推荐

每个用户的推荐列表都是热点数据，存在 Caffeine 里，快速返回；Redis 存全局的热点文章，当用户的推荐列表更新时，异步同步到 Redis。

3. 金融风控：实时风险数据

风控系统需要实时获取用户的交易数据，Caffeine 存最近 10 分钟的交易记录，Redis 存最近 1 小时的，数据库存全量数据，分层处理，保证风控规则的实时性。

4. 日志分析：实时统计指标

比如实时 PV、UV 统计，Caffeine 存当前分钟的统计数据，每分钟结束后同步到 Redis，Redis 按小时汇总，最后写入数据库，减少数据库压力。

结语：是时候给你的系统找个 CP 了

Redis 和 Caffeine 的组合，就像程序员的左右手，左手快速处理日常任务（本地热点），右手搞定复杂问题（分布式存储）。别再让你的系统单打独斗了，赶紧组个 CP，让性能飞起来。

不过，缓存虽好，可不要贪杯哦。一定要根据业务场景选择合适的策略，做好监控和容灾，毕竟再厉害的 CP 也需要用心维护。