Redis + Caffeine 太强了！这对缓存CP如何让系统性能原地起飞？

一、引言：当缓存遇到瓶颈，你需要一对「王炸组合」

凌晨三点被缓存雪崩报警惊醒？热点数据把 Redis 压得喘不过气？单靠分布式缓存或本地缓存早已不够看！在高并发场景下，\ Redis（分布式缓存扛把子）+ Caffeine（本地缓存性能王者）\ 的黄金组合，就像程序员的左右手 —— 左手快速处理本地热点，右手搞定分布式存储，让系统性能直接「炸场」。本文带你拆解这对 CP 的核心玩法，附实战攻略，看完直接落地！

二、为什么说 Redis 和 Caffeine 是「天作之合」？

（一）单飞的局限：Redis vs Caffeine 的「各自烦恼」

Redis 和 Caffeine，这两个在缓存界大名鼎鼎的角色，各自有着独特的优势，但当它们单飞时，也面临着一些难以忽视的局限。

先看 Redis，作为分布式缓存领域的「老大哥」，它凭借着强劲的实力在众多项目中占据了重大地位。Redis 能存储海量的数据，无论是简单的键值对，还是复杂的哈希、列表、集合等数据结构，它都能轻松应对。而且，Redis 还支持丰富的操作，列如原子操作、事务处理等，为开发者提供了极大的便利。

不过，Redis 也并非完美无缺。在高并发的场景下，网络延迟成为了它的一大痛点。即使是 1ms 的延迟，在百万并发的情况下，也会被无限放大，成为影响系统性能的黑洞。想象一下，每次请求都要在网络中来回传输数据，这中间的时间损耗会让系统的响应速度大打折扣。此外，带宽压力也是 Redis 面临的一个问题。当热点数据被频繁访问时，大量的数据传输会将网络带宽挤得水泄不通，甚至可能导致网络拥塞。

再来说说 Redis 集群的分片复杂度。在大规模的分布式系统中，为了提高 Redis 的性能和扩展性，一般会采用集群分片的方式。但是，如果键的设计不当，就会导致数据分布不均匀，某些节点负载过高，而某些节点则处于闲置状态。这样一来，不仅会影响查询效率，还可能引发一系列的性能问题。

接下来是 Caffeine，它作为本地缓存的「小快灵」代表，有着自己独特的魅力。Caffeine 基于 W-TinyLFU 算法实现了超高的命中率，这意味着它能够快速地从缓存中获取到所需的数据。而且，Caffeine 的访问速度极快，能够达到纳秒级，这使得它在处理高频访问的场景时表现出色。

不过，Caffeine 也存在一些短板。第一，它的内存容量有限，无法存储全量的数据。毕竟，它是基于本地内存的缓存，内存资源是有限的。当缓存的数据量超过了内存的承载能力，就会触发淘汰策略，将一些数据从缓存中移除。其次，Caffeine 存在进程隔离的问题。在分布式环境下，每个服务实例都有自己独立的 Caffeine 缓存，这就导致了数据无法在不同的进程之间共享。如果一个数据在某个进程中被更新了，其他进程中的 Caffeine 缓存并不能及时感知到这个变化，从而可能导致数据不一致的问题。最后，Caffeine 没有持久化功能，一旦进程重启，缓存中的数据就会全部消失。这对于一些对数据持久性要求较高的场景来说，是一个致命的缺陷。

（二）CP 合体的核心优势：冷热数据分层，榨干性能最后 1%

既然 Redis 和 Caffeine 单飞都有各自的局限，那么当它们组合在一起时，又会产生怎样的化学反应呢？答案就是冷热数据分层，这种组合方式能够充分发挥两者的优势，榨干系统性能的最后 1%。

在这种架构中，Caffeine 作为一级缓存，负责存储最热的数据。这些数据一般是高频访问的，列如电商平台中高频访问的商品详情、用户会话等。由于 Caffeine 是基于本地内存的缓存，所以可以直接从本地内存中读取数据，实现秒级响应。这样一来，大部分的高频请求都可以在本地得到快速处理，大大减少了网络传输的开销，提高了系统的响应速度。

而 Redis 则作为二级缓存，存储次热数据。Redis 的分布式特性使得它能够跨节点共享数据，从而有效地应对分布式环境下的各种挑战。当 Caffeine 缓存未命中时，请求会被转发到 Redis 缓存中。由于 Redis 存储的数据量相对较大，所以能够满足大部分的查询需求。而且，Redis 的高可用性和扩展性也保证了在高并发场景下的稳定性和可靠性。

在整个架构的最底层，是数据库作为保底。只有当缓存层（Caffeine 和 Redis）都未命中时，才会去查询数据库。通过这种三层架构的设计，能够让 99% 的请求在缓存层得到解决，数据库的压力直降 90%！这不仅提高了系统的性能和响应速度，还大大降低了数据库的负载，提高了系统的整体稳定性。

三、从架构到落地：这对 CP 的「甜蜜连招」怎么打？

（一）基础架构：两级缓存的「标准连招」流程

在实际应用中，Redis 和 Caffeine 组合的两级缓存架构是如何工作的呢？下面我们通过一个具体的示例来详细了解一下。

以电商系统中商品详情页的数据获取为例，当用户请求查看某个商品的详情时，系统会第一在 Caffeine 缓存中查找该商品的数据。这就好比我们在自己的办公桌抽屉里寻找常用的文件，由于 Caffeine 是本地缓存，数据存储在应用程序的内存中，所以查找速度超级快，能够在极短的时间内返回结果。如果 Caffeine 缓存中存在该商品的数据，就直接将数据返回给用户，整个过程几乎是瞬间完成的。

假设 Caffeine 缓存中没有找到该商品的数据，系统就会进入下一个步骤，到 Redis 缓存中去查找。这就像是我们在办公室的公共文件柜中查找文件，虽然 Redis 缓存的数据存储在远程服务器上，需要通过网络进行访问，但是由于 Redis 采用了高效的数据结构和算法，并且一般会部署在高性能的服务器集群上，所以它的查询速度也相当快。如果 Redis 缓存中存在该商品的数据，就将数据返回给用户，同时，为了提高下次查询的速度，还会将这份数据存入 Caffeine 缓存中，以便下次直接从本地缓存中获取。

要是 Redis 缓存中也没有找到该商品的数据，那就只能去数据库中查询了。这就好比我们要去档案室查找一份超级不常用的文件，数据库的查询速度相对较慢，由于它需要进行磁盘 I/O 操作，读取存储在磁盘上的数据。当从数据库中查询到商品数据后，将数据返回给用户，同时也会将数据存入 Redis 缓存和 Caffeine 缓存中，这样下次再有用户请求该商品的数据时，就可以直接从缓存中获取，而不需要再去查询数据库了。

通过这样的两级缓存架构，大部分的请求都可以在缓存层得到解决，只有极少数的请求需要去查询数据库，从而大大提高了系统的性能和响应速度，降低了数据库的压力。

（二）数据同步：如何避免「抽屉」与「仓库」数据打架？

在两级缓存架构中，数据同步是一个超级关键的问题，它直接关系到系统的数据一致性和稳定性。如果 Caffeine 缓存（我们可以把它看作是办公桌的抽屉）和 Redis 缓存（可以看作是办公室的公共仓库）之间的数据不一致，就会导致用户在不同的时间或者不同的节点上获取到不同的数据，这显然是我们不希望看到的。下面我们就来介绍几种常见的数据同步策略。

1. 失效模式（Cache-Aside，最常用）

失效模式是一种最常用的数据同步策略，它的核心思想是在数据更新时，先更新数据库，然后删除 Caffeine 和 Redis 中的旧缓存。这样，下次查询数据时，由于缓存中已经没有旧数据，系统就会从数据库中读取最新的数据，并将其存入缓存中，从而保证了数据的一致性。

具体来说，在读取数据时，先查 Caffeine，如果 Caffeine 中没有数据，再查 Redis，最后查 DB。当从 DB 中获取到数据后，会逐层回填到 Redis 和 Caffeine 中。在写入数据时，先更新 DB，然后再删除 Caffeine 和 Redis 的旧缓存。这里需要特别注意删除的顺序，必定要先删本地的 Caffeine 缓存，再删 Redis 缓存。这是由于如果先删 Redis 缓存，在高并发的情况下，可能会出现一个线程在删除 Redis 缓存后，还没来得及删除 Caffeine 缓存时，另一个线程就从 Caffeine 缓存中读取到了旧数据，从而导致脏数据的出现。

2. 异步更新（Write-Behind）

异步更新策略适用于对数据一致性要求不高的场景，列如日志记录等。在这种策略下，写操作不会直接更新数据库和缓存，而是先将数据放入一个队列中。然后，后台会有一个异步线程从队列中取出数据，再去更新两级缓存。这种方式的好处是可以提高系统的写入性能，由于写操作不需要等待数据库和缓存的更新完成，就可以返回给用户。

但是，异步更新策略也存在必定的风险。如果服务在异步更新完成之前挂掉了，队列里的数据就可能会丢失，从而导致数据不一致。为了避免这种情况的发生，一般需要搭配持久化队列使用，列如 Kafka、RocketMQ 等。这些持久化队列可以保证数据在服务重启后依旧存在，从而确保数据的可靠性。

3. 订阅发布（Pub/Sub）

订阅发布策略利用了 Redis 的发布订阅功能。当数据更新时，系统会向 Redis 发送一个发布事件，所有订阅了该事件的服务实例收到事件后，会删除本地的 Caffeine 缓存。这样，下次查询数据时，就会从 Redis 中加载最新的数据。

我们可以把这个过程想象成班长通知全班同学交作业，当班长发布了交作业的通知后，每个同学（服务实例）收到通知后，就会把自己的旧作业（本地缓存）删掉，下次老师（查询请求）来收作业时，同学们就会拿出新的作业（从 Redis 加载的最新数据）。这种方式可以有效地保证分布式环境下各个节点的缓存数据一致性，但是它也增加了系统的复杂性和网络开销，由于每次数据更新都需要进行一次发布订阅操作。

（三）淘汰策略：抽屉满了扔什么？仓库怎么配合？

在使用缓存的过程中，我们常常会遇到一个问题，那就是缓存空间是有限的，当缓存满了之后，就需要淘汰一些数据，为新的数据腾出空间。那么，应该淘汰哪些数据呢？这就涉及到缓存的淘汰策略了。对于 Redis + Caffeine 的两级缓存架构来说，它们各自有着不同的淘汰策略，并且相互配合，以达到最佳的缓存效果。

1. Caffeine 三板斧

Caffeine 提供了三种常见的淘汰策略，我们可以把它们想象成整理办公桌抽屉时的三种思路。

LRU（最近最少用）：这种策略就像是淘汰很久没碰的 “过时工具”。在 Caffeine 中，如果一个数据很久没有被访问过，那么它就会被认为是不常用的数据，当缓存空间不足时，就会优先被淘汰掉。列如，我们抽屉里有一个计算器，已经一年都没有用过了，那么在整理抽屉时，这个计算器就很有可能被我们扔掉。
LFU（最不常用）：LFU 策略类似于淘汰用得少的 “积灰 U 盘”。它会统计每个数据的访问频率，当缓存满了之后，优先淘汰访问频率最低的数据。列如，我们抽屉里有一个 U 盘，虽然最近用过，但是使用的次数超级少，那么在空间有限的情况下，这个 U 盘就可能会被我们清理掉。
TTL（生存时间）：TTL 策略就像是到期自动删除 “过期零食”。我们可以为每个缓存数据设置一个生存时间，当数据的生存时间到期后，无论它是否被访问过，都会自动从缓存中删除。列如，我们在抽屉里放了一些零食，并且给它们设定了一个保质期，当保质期一过，这些零食就会被我们扔掉。

在实际应用中，最佳实践是采用 LRU + TTL 组合的方式。对于热点数据，我们可以设置较长的 TTL，列如 1 小时，这样可以保证热点数据在缓存中停留较长的时间，提高查询效率。而对于普通数据，则可以按照 LRU 策略进行淘汰，以保证缓存中始终存储着最常用的数据。

2. Redis 互补策略

Redis 作为二级缓存，也有自己的淘汰策略。一般情况下，我们会配置 Redis 的 allkeys – lru 淘汰策略。这种策略会在缓存达到最大内存限制时，淘汰整个键空间中最近最少使用的键。通过这种方式，Redis 与 Caffeine 形成了冷热分层。Caffeine 主要存储最热的数据，而 Redis 则存储次热数据，当 Caffeine 中的数据被淘汰后，如果这些数据还有必定的热度，就会被存储到 Redis 中，这样可以避免内存的浪费，同时也保证了数据的可用性。

（四）性能优化：这 20% 的提速细节决定成败

在构建 Redis + Caffeine 两级缓存架构时，除了合理设计架构、选择合适的数据同步策略和淘汰策略外，还有一些性能优化的细节不容忽视。这些细节虽然看似微不足道，但却可能对系统的性能产生重大影响，甚至可以让系统的速度再提升 20%。下面我们就来详细介绍一下这些性能优化的方法。

1. 序列化优化

在数据存储和传输过程中，序列化是一个必不可少的环节。Caffeine 存储的是 Java 对象，由于它是在本地内存中进行操作，所以可以直接存储 Java 对象，无需进行序列化，这大大提高了数据的读写速度。而 Redis 存储的是字节数组，当我们将 Java 对象存储到 Redis 中时，需要先进行序列化，将 Java 对象转换为字节数组，在读取时再进行反序列化，将字节数组转换回 Java 对象。

在这个过程中，序列化方式的选择就显得尤为重大。传统的 JDK 序列化方式虽然简单易用，但是它存在一些明显的缺点，列如序列化后的字节数组体积较大，会占用较多的网络带宽和 Redis 存储空间，而且序列化和反序列化的速度也比较慢。为了提高性能，我们推荐使用 Protostuff 或 Kryo 来替代 JDK 序列化。这两种序列化框架具有更高的性能，它们可以将对象序列化为更紧凑的字节数组，体积相比 JDK 序列化可以压缩 50% 左右，同时序列化和反序列化的速度也更快，能够提升 3 倍左右。这样一来，不仅可以减少网络传输的时间，还可以提高 Redis 的存储效率，从而提升整个系统的性能。

2. 并发控制

在高并发环境下，并发控制是保证系统稳定性和数据一致性的关键。Caffeine 由于其底层基于 Java 8 的 ConcurrentHashMap 实现，天生具有线程安全的特性，并且采用了无锁设计，这使得它在高并发场景下能够保持高效的读写性能。在 Caffeine 中，多个线程可以同时对缓存进行读写操作，而不会出现数据竞争和线程安全问题。

而对于 Redis 操作，由于它是分布式缓存，多个服务实例可能会同时对同一个键进行读写操作，这就需要思考分布式锁的问题。为了防止缓存击穿（即大量并发请求同时访问一个失效的缓存键，导致这些请求直接穿透到数据库，给数据库带来巨大压力），我们可以使用 Redisson 提供的分布式可重入锁。当一个服务实例需要对某个 Redis 键进行写操作时，它第一会尝试获取分布式锁，如果获取成功，就可以进行写操作，在操作完成后释放锁；如果获取锁失败，说明其他服务实例正在进行写操作，当前实例就需要等待，直到获取到锁为止。通过这种方式，可以有效地避免多个实例同时更新缓存导致的数据不一致问题，保证系统在高并发场景下的稳定性。

3. 预热机制

在系统启动时，缓存中一般是空的，这就意味着第一个请求进来时，需要从数据库中查询数据并填充到缓存中，这个过程被称为冷启动。冷启动会导致请求的响应时间变长，影响用户体验。为了避免这种情况，我们可以采用预热机制。

在系统启动时，通过 caffeineCache.putAll (hotDataMap) 方法预加载热点数据到 Caffeine 缓存中。hotDataMap 是一个包含热点数据的 Map，其中键是缓存键，值是对应的缓存值。通过这种方式，在系统启动后，Caffeine 缓存中就已经包含了热点数据，当第一个请求进来时，就可以直接从缓存中获取数据，避免了冷启动的延迟。这就好比我们在早上上班前，提前把当天需要用到的工具都准备好放在办公桌上，这样当工作开始时，我们就可以直接使用这些工具，而不需要再花费时间去寻找，从而提高了工作效率。

四、实战案例：电商秒杀场景如何靠这对 CP 扛住 10 万 QPS？

（一）场景痛点

在电商领域，秒杀活动一直是对系统性能的巨大考验。以某知名电商平台的一次大型促销活动为例，活动期间，商品详情页的访问量瞬间突增 10 倍，达到了惊人的 10 万 QPS。在这样的高并发压力下，原本依赖单 Redis 缓存的系统出现了严重的性能瓶颈。

Redis 虽然在分布式缓存领域表现出色，但在高并发场景下，网络延迟成为了无法忽视的问题。由于大量的请求同时涌向 Redis 服务器，网络带宽被迅速占满，导致响应时间急剧增加，甚至出现了响应超时的情况。这不仅影响了用户的购物体验，还导致了大量的订单流失。

此外，单机 Caffeine 缓存也面临着内存不足的问题。由于秒杀活动的特殊性，热点商品的数据量远远超过了 Caffeine 的内存承载能力，无法将所有热点商品的数据都存储在本地缓存中。这就导致了 Caffeine 缓存的命中率急剧下降，大量的请求不得不穿透到 Redis 缓存，进一步加剧了 Redis 的压力。

（二）解决方案

为了解决这些问题，该电商平台采用了 Redis + Caffeine 的两级缓存架构，具体的优化策略如下：

分层设计：Caffeine 设置 maximumSize (10000)，用于存储 Top 10000 的热销商品，同时设置 expireAfterWrite (10, MINUTES)，以确保缓存数据的时效性。而 Redis 作为二级缓存，存储全量商品数据，并采用集群部署的方式，以应对分布式压力。这样的分层设计，使得热点数据能够在本地缓存中快速获取，减少了网络传输的开销，提高了系统的响应速度。
流量拦截：通过两级缓存的协作，实现了流量的有效拦截。经过实际测试，90% 的请求都能够在 Caffeine 层命中，只有剩余 10% 的请求需要走 Redis。而数据库仅处理缓存穿透的 0.1% 请求，这大大减轻了数据库的压力，提高了系统的整体吞吐量。
一致性保障：在秒杀库存扣减时，为了确保数据的一致性，采用了先更新 DB，再通过 Redis Pub/Sub 通知所有节点删除本地缓存的策略。这样，当下一次查询时，就能获取到最新的库存信息，避免了超卖等问题的发生。具体来说，当一个用户下单成功后，系统会第一更新数据库中的库存信息，然后通过 Redis 的发布订阅功能，向所有订阅了该商品库存更新事件的节点发送通知。这些节点在收到通知后，会立即删除本地 Caffeine 缓存中该商品的库存信息，从而保证了缓存数据与数据库数据的一致性。

（三）效果对比

在采用了 Redis + Caffeine 的两级缓存架构后，该电商平台的秒杀活动取得了显著的效果提升。具体的数据对列如下：

指标	单 Redis 方案	Redis+Caffeine 方案
平均响应时间	8ms	1.5ms
数据库 QPS	20000	2000
缓存命中率	85%	98%

从数据中可以明显看出，Redis + Caffeine 方案的平均响应时间大幅缩短，从 8ms 降低到了 1.5ms，这使得用户在秒杀活动中能够更快地获取商品信息，提高了用户体验。数据库 QPS 也大幅下降，从 20000 降低到了 2000，这减轻了数据库的压力，提高了系统的稳定性。而缓存命中率则从 85% 提升到了 98%，这意味着更多的请求能够在缓存层得到解决，减少了对数据库的访问，进一步提高了系统的性能。

五、避坑指南：这 3 个陷阱千万别踩！

在享受 Redis + Caffeine 带来的高性能时，也有一些容易踩坑的地方需要注意。下面我为大家总结了 3 个常见的陷阱以及相应的解决方案，协助大家在使用过程中少走弯路。

（一）内存溢出风险：Caffeine 必须设置 maximumSize，配合 expireAfterWrite，避免单节点内存被撑爆

Caffeine 作为本地缓存，直接占用应用程序的内存。如果不设置 maximumSize，当缓存数据量不断增加时，可能会导致应用程序的内存被耗尽，从而引发内存溢出错误（OOM）。这就好比你的办公桌抽屉没有容量限制，你不断地往里面塞东西，最终抽屉被塞得满满当当，再也塞不进去任何东西，甚至可能把抽屉撑坏。

为了避免这种情况的发生，我们必须为 Caffeine 设置合理的 maximumSize。这个值需要根据应用程序的实际内存情况和业务需求来确定。同时，配合 expireAfterWrite 设置缓存的过期时间，让不再使用的数据能够及时从缓存中移除，为新的数据腾出空间。这样，我们的 “办公桌抽屉” 就能始终保持在一个合理的使用状态，避免由于数据过多而导致内存溢出的问题。

（二）数据不一致坑：写操作务必先更新 DB 再删缓存，禁止先删缓存再更新 DB（并发场景下必出脏数据）

在进行数据更新操作时，数据一致性是一个超级重大的问题。如果操作顺序不当，就可能会导致缓存和数据库中的数据不一致，从而影响系统的正常运行。

假设我们采用先删缓存再更新 DB 的操作顺序。在高并发的情况下，可能会出现这样的场景：线程 A 删除了缓存后，还没来得及更新 DB，线程 B 就发起了查询请求。由于缓存中已经没有数据，线程 B 会从 DB 中读取旧数据，并将其重新存入缓存中。随后，线程 A 更新了 DB，但此时缓存中的数据已经是旧数据了，这就导致了缓存和 DB 的数据不一致。

为了避免这种情况的发生，我们应该始终遵循先更新 DB 再删缓存的操作顺序。这样，即使在高并发的情况下，也能保证缓存和 DB 的数据最终是一致的。虽然在更新 DB 和删除缓存之间可能会有短暂的时间差，但由于这个时间差超级小，在实际应用中可以忽略不计。

（三）Redis 压力反弹：避免在 Caffeine 中存储大对象（如 1MB 以上），防止 Redis 带宽被回填操作拖垮，提议存 ID 而非完整对象

当 Caffeine 缓存未命中时，会从 Redis 中读取数据，并将数据回填到 Caffeine 中。如果在 Caffeine 中存储了大对象（如 1MB 以上），那么在回填过程中，会产生大量的数据传输，这将极大地占用 Redis 的带宽资源，甚至可能导致 Redis 的带宽被拖垮。这就好比一条原本宽敞的道路，突然涌入了大量的大型货车，导致交通堵塞，车辆无法正常通行。

为了避免这种情况的发生，我们应该尽量避免在 Caffeine 中存储大对象。如果的确需要存储大对象，可以思考只存储对象的 ID，而不是完整的对象。当需要使用对象的详细信息时，再通过 ID 从 Redis 或 DB 中获取完整的对象。这样，在回填过程中，只需要传输对象的 ID，而不是整个大对象，从而大大减少了数据传输量，降低了对 Redis 带宽的压力。

六、总结：这对 CP，谁用谁知道！

Redis+Caffeine 的组合，本质是「本地高性能 + 分布式扩展性」的完美平衡，在电商秒杀、金融配置缓存、高频接口加速等场景中屡试不爽。通过冷热数据分层、合理同步策略和性能优化，这套方案能让系统吞吐量提升 5 倍以上，数据库压力骤减，堪称「性价比之王」。：你在项目中遇到过哪些缓存难题？这对 CP 能解决你的问题吗？评论区聊聊！（觉得有用就点赞收藏，关注我，持续分享分布式架构实战干货！）