Redis最常用的一个场景就是作为缓存，本文主要探讨Redis作为缓存，在实践中可能会有哪些问题？比如一致性, 穿击, 穿透, 雪崩, 污染等。

为什么要理解Redis缓存问题

在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。所以，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问Mysql等数据库。这样可以大大缓解数据库的压力。

当缓存库出现时，必须要考虑如下问题：

缓存穿透
缓存穿击
缓存雪崩
缓存污染（或者满了）
缓存和数据库一致性

缓存穿透

1. 问题本质

缓存穿透是指 查询一个不存在的数据，导致请求绕过缓存直接访问数据库。由于数据库也没有该数据，无法回填缓存，导致恶意请求反复穿透缓存压垮数据库。

2. 攻击场景

恶意请求：如频繁查询 id=-1 或超大ID等不存在的数据。
漏洞利用：利用业务接口缺陷伪造非法参数。

3. 解决方案对比

(1) 参数校验（最基础防御）

实现：在API层拦截明显非法请求（如非正整数ID、超长字符串）。
优点：简单高效，拦截80%低级攻击。
缺点：无法防御精心构造的合法参数（如随机不存在的ID）。

示例代码：

if (id <= 0 || id > MAX_ID) {throw new IllegalArgumentException("非法ID");
}

(2) 缓存空值（简单有效）

实现：数据库未命中时，缓存 key-null 并设置短TTL（如30秒）。
优点：避免同一Key反复穿透。
缺点：

- 内存浪费（需存储大量空值）。
- 短时间仍可能被攻击（如海量不同Key）。

示例代码：

String data = cache.get(key);
if (data == null) {data = db.query(key);if (data == null) { // 数据库不存在cache.set(key, "NULL", 30); // 缓存空值} else {cache.set(key, data, 3600);}
}
return "NULL".equals(data) ? null : data;

(3) 布隆过滤器（终极防御）

原理：

- 使用位数组和哈希函数，判断元素 “一定不存在” 或 “可能存在”。
- 将所有合法Key预先存入布隆过滤器，查询前先检查过滤器。

优点：

- 内存占用极低（1亿Key约占用12MB）。
- 拦截不存在Key的效率接近O(1)。

缺点：

- 误判率：可能将不存在的Key误判为存在（可通过调整哈希函数和数组大小控制）。
- 无法删除：传统布隆过滤器不支持删除（需用变种如Counting Bloom Filter）。

实现示例（Guava库）：

BloomFilter<String> filter = BloomFilter.create(Funnels.stringFunnel(), 1000000, // 预期元素数量0.01     // 误判率
);// 预热数据
for (String validKey : allValidKeys) {filter.put(validKey);
}// 查询前检查
if (!filter.mightContain(key)) {return null; // 绝对不存在
}

缓存击穿

缓存击穿（Cache Breakdown）是缓存系统中的一种典型问题，通常发生在高并发访问某个热点数据时，该数据恰好缓存过期，导致大量请求瞬间穿透缓存直接压垮数据库。

问题本质

触发条件：

- 缓存中的热点Key过期（如秒杀商品、首页头条）。
- 同时有大量并发请求访问该Key。

直接后果：

- 所有请求绕过缓存，直接查询数据库。
- 数据库短时间内承受极高QPS（可能崩溃）。

解决方案及实现

方案1：热点数据永不过期

适用场景：极高频访问且数据更新不频繁（如配置信息）。
实现方式：

- 物理永不过期：缓存不设TTL。
- 逻辑续期：异步检查数据版本，有更新时重新加载缓存。

优点：彻底避免击穿。
缺点：数据更新不及时（需结合其他机制如消息队列通知）。

// 示例：逻辑续期（伪代码）
public String getHotData(String key) {String data = cache.get(key);if (data == null) {data = loadFromDB(key);cache.set(key, data); // 不设置过期时间scheduleRefresh(key); // 异步定时刷新}return data;
}

方案2：互斥锁（Mutex Lock）

核心思想：只允许一个请求重建缓存，其他请求阻塞或轮询等待。
实现方式：

- 分布式锁：如Redis的 SETNX（推荐）。
- 本地锁：仅单机有效（如Java的 synchronized）。

分布式锁实现（Redis）

public String getDataWithLock(String key) {String data = cache.get(key);if (data == null) {String lockKey = "lock:" + key;try {// 尝试获取分布式锁（SETNX + 超时）boolean locked = redis.setnx(lockKey, "1", 10, TimeUnit.SECONDS);if (locked) {data = loadFromDB(key);          // 查数据库cache.set(key, data, 1, TimeUnit.HOURS); // 回填缓存} else {Thread.sleep(100);              // 短暂等待后重试return getDataWithLock(key);    // 递归调用}} finally {redis.del(lockKey);                 // 释放锁}}return data;
}

优点：保证数据库不会被重复查询。
缺点：

- 锁竞争可能导致部分请求延迟。
- 需处理锁超时和死锁问题。

方案3：限流与熔断降级

适用场景：突发流量无法用缓存完全拦截时（如明星出轨新闻）。
实现工具：

- 限流：Guava RateLimiter、Sentinel、Nginx。
- 熔断：Hystrix、Resilience4j。

示例：

// Guava 限流（每秒10个请求）
RateLimiter limiter = RateLimiter.create(10.0);
public String getDataWithRateLimit(String key) {if (!limiter.tryAcquire()) {return "系统繁忙，请稍后再试"; // 降级响应}return getData(key); // 正常逻辑
}

优点：保护数据库不被突发流量击垮。
缺点：可能误伤正常用户请求。

缓存雪崩

问题本质

缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

触发条件

大批量Key同时过期：如缓存数据初始化时设置了相同的TTL（如默认1小时）。
缓存服务宕机：Redis集群崩溃，所有请求直接打到数据库。

解决方案

缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
如果缓存数据库是分布式部署，将热点数据均匀分布在不同的缓存数据库中。（缓存服务高可用）
设置热点数据永远不过期。

缓存污染（或满了）

缓存污染问题说的是缓存中一些只会被访问一次或者几次的的数据，被访问完后，再也不会被访问到，但这部分数据依然留存在缓存中，消耗缓存空间。

缓存污染会随着数据的持续增加而逐渐显露，随着服务的不断运行，缓存中会存在大量的永远不会再次被访问的数据。缓存空间是有限的，如果缓存空间满了，再往缓存里写数据时就会有额外开销，影响Redis性能。这部分额外开销主要是指写的时候判断淘汰策略，根据淘汰策略去选择要淘汰的数据，然后进行删除操作。

最大缓存设置多大

系统的设计选择是一个权衡的过程：大容量缓存是能带来性能加速的收益，但是成本也会更高，而小容量缓存不一定就起不到加速访问的效果。一般来说，我会建议把缓存容量设置为总数据量的 15% 到 30%，兼顾访问性能和内存空间开销。

对于 Redis 来说，一旦确定了缓存最大容量，比如 4GB，你就可以使用下面这个命令来设定缓存的大小了：

CONFIG SET maxmemory 4gb

不过，缓存被写满是不可避免的, 所以需要数据淘汰策略。

缓存淘汰策略

Redis共支持八种淘汰策略，分别是noeviction、volatile-random、volatile-ttl、volatile-lru、volatile-lfu、allkeys-lru、allkeys-random 和 allkeys-lfu 策略。

怎么理解呢？主要看分三类看：

不淘汰

- noeviction （v4.0后默认的）

对设置了过期时间的数据中进行淘汰

- 随机：volatile-random
- ttl：volatile-ttl
- lru：volatile-lru
- lfu：volatile-lfu

全部数据进行淘汰

- 随机：allkeys-random
- lru：allkeys-lru
- lfu：allkeys-lfu

具体对照下：

1. noeviction

该策略是Redis的默认策略。在这种策略下，一旦缓存被写满了，再有写请求来时，Redis 不再提供服务，而是直接返回错误。这种策略不会淘汰数据，所以无法解决缓存污染问题。一般生产环境不建议使用。

其他七种规则都会根据自己相应的规则来选择数据进行删除操作。

2. volatile-random

这个算法比较简单，在设置了过期时间的键值对中，进行随机删除。因为是随机删除，无法把不再访问的数据筛选出来，所以可能依然会存在缓存污染现象，无法解决缓存污染问题。

3. volatile-ttl

这种算法判断淘汰数据时参考的指标比随机删除时多进行一步过期时间的排序。Redis在筛选需删除的数据时，越早过期的数据越优先被选择。

4. volatile-lru

LRU算法：LRU 算法的全称是 Least Recently Used，按照最近最少使用的原则来筛选数据，优先淘汰 最久未被访问 的数据（基于最近访问时间）。这种模式下会使用 LRU 算法筛选设置了过期时间的键值对。

Redis优化的LRU算法实现：

Redis会记录每个数据的最近一次被访问的时间戳。在Redis在决定淘汰的数据时，第一次会随机选出 N 个数据，把它们作为一个候选集合。接下来，Redis 会比较这 N 个数据的 lru 字段，把 lru 字段值最小的数据从缓存中淘汰出去。通过随机读取待删除集合，可以让Redis不用维护一个巨大的链表，也不用操作链表，进而提升性能。

Redis 选出的数据个数 N，通过配置参数 maxmemory-samples 进行配置。个数N越大，则候选集合越大，选择到的最久未被使用的就更准确，N越小，选择到最久未被使用的数据的概率也会随之减小。

5. volatile-lfu

优先淘汰 访问频率最低 的数据，频率相同则淘汰最久未访问的。会使用 LFU 算法选择设置了过期时间的键值对。

LFU 算法：LFU 缓存策略是在 LRU 策略基础上，为每个数据增加了一个计数器，来统计这个数据的访问次数。当使用 LFU 策略筛选淘汰数据时，首先会根据数据的访问次数进行筛选，把访问次数最低的数据淘汰出缓存。如果两个数据的访问次数相同，LFU 策略再比较这两个数据的访问时效性，把距离上一次访问时间更久的数据淘汰出缓存。 Redis的LFU算法实现:

当 LFU 策略筛选数据时，Redis 会在候选集合中，根据数据 lru 字段的后 8bit 选择访问次数最少的数据进行淘汰。当访问次数相同时，再根据 lru 字段的前 16bit 值大小，选择访问时间最久远的数据进行淘汰。

Redis 只使用了 8bit 记录数据的访问次数，而 8bit 记录的最大值是 255，这样在访问快速的情况下，如果每次被访问就将访问次数加一，很快某条数据就达到最大值255，可能很多数据都是255，那么退化成LRU算法了。所以Redis为了解决这个问题，实现了一个更优的计数规则，并可以通过配置项，来控制计数器增加的速度。

参数：

lfu-log-factor ，用计数器当前的值乘以配置项 lfu_log_factor 再加 1，再取其倒数，得到一个 p 值；然后，把这个 p 值和一个取值范围在（0，1）间的随机数 r 值比大小，只有 p 值大于 r 值时，计数器才加 1。

lfu-decay-time，控制访问次数衰减。LFU 策略会计算当前时间和数据最近一次访问时间的差值，并把这个差值换算成以分钟为单位。然后，LFU 策略再把这个差值除以 lfu_decay_time 值，所得的结果就是数据 counter 要衰减的值。

lfu-log-factor设置越大，递增概率越低，lfu-decay-time设置越大，衰减速度会越慢。

我们在应用 LFU 策略时，一般可以将 lfu_log_factor 取值为 10。如果业务应用中有短时高频访问的数据的话，建议把 lfu_decay_time 值设置为 1。可以快速衰减访问次数。

volatile-lfu 策略是 Redis 4.0 后新增。

6. allkeys-lru

使用 LRU 算法在所有数据中进行筛选。具体LFU算法跟上述 volatile-lru 中介绍的一致，只是筛选的数据范围是全部缓存，这里就不在重复。

7. allkeys-random

从所有键值对中随机选择并删除数据。volatile-random 跟 allkeys-random算法一样，随机删除就无法解决缓存污染问题。

8. allkeys-lfu

使用 LFU 算法在所有数据中进行筛选。具体LFU算法跟上述 volatile-lfu 中介绍的一致，只是筛选的数据范围是全部缓存，这里就不在重复。

allkeys-lfu 策略是 Redis 4.0 后新增。

数据库和缓存一致性

问题来源

使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问MySQL等数据库：

读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。

不管是先写MySQL数据库，再删除Redis缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。举一个例子：

1.如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。

2.如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。

因为写和读是并发的，没法保证顺序，就会出现缓存和数据库的数据不一致的问题。

4种相关模式

更新缓存的的Design Pattern有四种：Cache aside, Read through, Write through, Write behind caching;

节选最最常用的Cache Aside Pattern, 总结来说就是

读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
更新的时候，先更新数据库，然后再删除缓存。

其具体逻辑如下：

失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
命中：应用程序从cache中取数据，取到后返回。
更新：先把数据存到数据库中，成功后，再让缓存失效。

注意，我们的更新是先更新数据库，成功后，让缓存失效。那么，这种方式是否可以没有文章前面提到过的那个问题呢？我们可以脑补一下。

一个是查询操作，一个是更新操作的并发，首先，没有了删除cache数据的操作了，而是先更新了数据库中的数据，此时，缓存依然有效，所以，并发的查询操作拿的是没有更新的数据，但是，更新操作马上让缓存的失效了，后续的查询操作再把数据从数据库中拉出来。而不会像文章开头的那个逻辑产生的问题，后续的查询操作一直都在取老的数据。

这是标准的design pattern，包括Facebook的论文《Scaling Memcache at Facebook》也使用了这个策略。为什么不是写完数据库后更新缓存？你可以看一下Quora上的这个问答《Why does Facebook use delete to remove the key-value pair in Memcached instead of updating the Memcached during write request to the backend?》，主要是怕两个并发的写操作导致脏数据。

那么，是不是Cache Aside这个就不会有并发问题了？不是的，比如，一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后，之前的那个读操作再把老的数据放进去，所以，会造成脏数据。

但，这个case理论上会出现，不过，实际上出现的概率可能非常低，因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必需在写操作前进入数据库操作，而又要晚于写操作更新缓存，所有的这些条件都具备的概率基本并不大。

所以，这也就是Quora上的那个答案里说的，要么通过2PC或是Paxos协议保证一致性，要么就是拼命的降低并发时脏数据的概率，而Facebook使用了这个降低概率的玩法，因为2PC太慢，而Paxos太复杂。当然，最好还是为缓存设置上过期时间。