Redis缓存穿透、缓存雪崩、redis并发问题并发竞争key的解决方案 (阿里)

阿里的人问我缓存雪崩（大量数据在同一时间过期了）了如何处理，缓存击穿了如何处理，回答的很烂，做了总结：

把redis作为缓存使用已经是司空见惯，但是使用redis后也可能会碰到一系列的问题，尤其是数据量很大的时候，经典的几个问题如下：

1. 缓存穿透

在大多数互联网应用中，缓存的使用方式如下图所示：

当业务系统发起某一个查询请求时，首先判断缓存中是否有该数据；
如果缓存中存在，则直接返回数据；
如果缓存中不存在，则再查询数据库，然后返回数据。

了解了上述过程后，下面说说缓存穿透。

1.1 什么是缓存穿透？

业务系统要查询的数据根本就不存在！当业务系统发起查询时，按照上述流程，首先会前往缓存中查询，由于缓存中不存在，然后再前往数据库中查询。由于该数据压根就不存在，因此数据库也返回空。这就是缓存穿透。

综上所述：业务系统访问压根就不存在的数据，就称为缓存穿透。

1.2 缓存穿透的危害

如果存在海量请求查询压根就不存在的数据，那么这些海量请求都会落到数据库中，数据库压力剧增，可能会导致系统崩溃（你要知道，目前业务系统中最脆弱的就是IO，稍微来点压力它就会崩溃，所以我们要想种种办法保护它）。

1.3 为什么会发生缓存穿透？

发生缓存穿透的原因有很多，一般为如下两种：

恶意攻击，故意营造大量不存在的数据请求我们的服务，由于缓存中并不存在这些数据，因此海量请求均落在数据库中，从而可能会导致数据库崩溃。
代码逻辑错误。这是程序员的锅，没啥好讲的，开发中一定要避免！

1.4 缓存穿透的解决方案

下面来介绍两种防止缓存穿透的手段。

1.4.1 缓存空数据

之所以发生缓存穿透，是因为缓存中没有存储这些空数据的key，导致这些请求全都打到数据库上。

那么，我们可以稍微修改一下业务系统的代码，将数据库查询结果为空的key也存储在缓存中。当后续又出现该key的查询请求时，缓存直接返回null，而无需查询数据库。

1.4.2 BloomFilter

第二种避免缓存穿透的方式即为使用BloomFilter。

它需要在缓存之前再加一道屏障，里面存储目前数据库中存在的所有key，如下图所示：

当业务系统有查询请求的时候，首先去BloomFilter中查询该key是否存在。若不存在，则说明数据库中也不存在该数据，因此缓存都不要查了，直接返回null。若存在，则继续执行后续的流程，先前往缓存中查询，缓存中没有的话再前往数据库中的查询。

1.4.3 两种方案的比较

这两种方案都能解决缓存穿透的问题，但使用场景却各不相同。

对于一些恶意攻击，查询的key往往各不相同，而且数据贼多。此时，第一种方案就显得提襟见肘了。因为它需要存储所有空数据的key，而这些恶意攻击的key往往各不相同，而且同一个key往往只请求一次。因此即使缓存了这些空数据的key，由于不再使用第二次，因此也起不了保护数据库的作用。
因此，对于空数据的key各不相同、key重复请求概率低的场景而言，应该选择第二种方案。而对于空数据的key数量有限、key重复请求概率较高的场景而言，应该选择第一种方案。

2. 缓存雪崩

2.1 什么是缓存雪崩？

通过上文可知，缓存其实扮演了一个保护数据库的角色。它帮数据库抵挡大量的查询请求，从而避免脆弱的数据库受到伤害。

如果缓存因某种原因发生了宕机，那么原本被缓存抵挡的海量查询请求就会像疯狗一样涌向数据库。此时数据库如果抵挡不了这巨大的压力，它就会崩溃。

这就是缓存雪崩。

2.2 如何避免缓存雪崩？

2.2.1 使用缓存集群，保证缓存高可用

也就是在雪崩发生之前，做好预防手段，防止雪崩的发生。
PS：关于分布式高可用问题不是今天讨论的重点，套路就那些，后面会有高可用的相关文章，尽请关注。

2.2.2 使用Hystrix

Hystrix是一款开源的“防雪崩工具”，它通过熔断、降级、限流三个手段来降低雪崩发生后的损失。

Hystrix就是一个Java类库，它采用命令模式，每一项服务处理请求都有各自的处理器。所有的请求都要经过各自的处理器。处理器会记录当前服务的请求失败率。一旦发现当前服务的请求失败率达到预设的值，Hystrix将会拒绝随后该服务的所有请求，直接返回一个预设的结果。这就是所谓的“熔断”。当经过一段时间后，Hystrix会放行该服务的一部分请求，再次统计它的请求失败率。如果此时请求失败率符合预设值，则完全打开限流开关；如果请求失败率仍然很高，那么继续拒绝该服务的所有请求。这就是所谓的“限流”。而Hystrix向那些被拒绝的请求直接返回一个预设结果，被称为“降级”。

更多Hystrix的介绍请参阅：https://segmentfault.com/a/1190000005988895

3. 热点数据集中失效

3.1 什么是热点数据集中失效？

我们一般都会给缓存设定一个失效时间，过了失效时间后，该数据库会被缓存直接删除，从而一定程度上保证数据的实时性。

但是，对于一些请求量极高的热点数据而言，一旦过了有效时间，此刻将会有大量请求落在数据库上，从而可能会导致数据库崩溃。其过程如下图所示：

如果某一个热点数据失效，那么当再次有该数据的查询请求[req-1]时就会前往数据库查询。但是，从请求发往数据库，到该数据更新到缓存中的这段时间中，由于缓存中仍然没有该数据，因此这段时间内到达的查询请求都会落到数据库上，这将会对数据库造成巨大的压力。此外，当这些请求查询完成后，都会重复更新缓存。

3.2 解决方案

3.2.1 互斥锁

我们可以使用缓存自带的锁机制，当第一个数据库查询请求发起后，就将缓存中该数据上锁；此时到达缓存的其他查询请求将无法查询该字段，从而被阻塞等待；当第一个请求完成数据库查询，并将数据更新值缓存后，释放锁；此时其他被阻塞的查询请求将可以直接从缓存中查到该数据。

当某一个热点数据失效后，只有第一个数据库查询请求发往数据库，其余所有的查询请求均被阻塞，从而保护了数据库。但是，由于采用了互斥锁，其他请求将会阻塞等待，此时系统的吞吐量将会下降。这需要结合实际的业务考虑是否允许这么做。

互斥锁可以避免某一个热点数据失效导致数据库崩溃的问题，而在实际业务中，往往会存在一批热点数据同时失效的场景。那么，对于这种场景该如何防止数据库过载呢？

3.3.2 设置不同的失效时间

当我们向缓存中存储这些数据的时候，可以将他们的缓存失效时间错开。这样能够避免同时失效。如：在一个基础时间上加/减一个随机数，从而将这些缓存的失效时间错开。

以上来自于阿里的大牛柴毛毛的博客，写的很有逻辑性，很有调理，可以作为面试的规范

(一)缓存和数据库间数据一致性问题
分布式环境下（单机就不用说了）非常容易出现缓存和数据库间的数据一致性问题，针对这一点的话，只能说，如果你的项目对缓存的要求是强一致性的，那么请不要使用缓存。我们只能采取合适的策略来降低缓存和数据库间数据不一致的概率，而无法保证两者间的强一致性。合适的策略包括合适的缓存更新策略，更新数据库后要及时更新缓存、缓存失败时增加重试机制，例如MQ模式的消息队列。

(二)缓存击穿问题
缓存击穿表示恶意用户模拟请求很多缓存中不存在的数据，由于缓存中都没有，导致这些请求短时间内直接落在了数据库上，导致数据库异常。这个我们在实际项目就遇到了，有些抢购活动、秒杀活动的接口API被大量的恶意用户刷，导致短时间内数据库c超时了，好在数据库是读写分离，同时也有进行接口限流，hold住了。

解决方案的话：

方案1、使用互斥锁排队

业界比价普遍的一种做法，即根据key获取value值为空时，锁上，从数据库中load数据后再释放锁。若其它线程获取锁失败，则等待一段时间后重试。这里要注意，分布式环境中要使用分布式锁，单机的话用普通的锁（synchronized、Lock）就够了。

public String getWithLock(String key, Jedis jedis, String lockKey, String uniqueId, long expireTime) {
// 通过key获取value
String value = redisService.get(key);
if (StringUtil.isEmpty(value)) {
// 分布式锁，详细可以参考https://blog.csdn.net/fanrenxiang/article/details/79803037
//封装的tryDistributedLock包括setnx和expire两个功能，在低版本的redis中不支持
try {
boolean locked = redisService.tryDistributedLock(jedis, lockKey, uniqueId, expireTime);
if (locked) {
value = userService.getById(key);
redisService.set(key, value);
redisService.del(lockKey);
return value;
} else {
// 其它线程进来了没获取到锁便等待50ms后重试
Thread.sleep(50);
getWithLock(key, jedis, lockKey, uniqueId, expireTime);
}
} catch (Exception e) {
log.error("getWithLock exception=" + e);
return value;
} finally {
redisService.releaseDistributedLock(jedis, lockKey, uniqueId);
}
}
return value;
}

这样做思路比较清晰，也从一定程度上减轻数据库压力，但是锁机制使得逻辑的复杂度增加，吞吐量也降低了，有点治标不治本。

方案2、接口限流与熔断、降级

重要的接口一定要做好限流策略，防止用户恶意刷接口，同时要降级准备，当接口中的某些服务不可用时候，进行熔断，失败快速返回机制。

方案3、布隆过滤器

bloomfilter就类似于一个hash set，用于快速判某个元素是否存在于集合中，其典型的应用场景就是快速判断一个key是否存在于某容器，不存在就直接返回。布隆过滤器的关键就在于hash算法和容器大小，下面先来简单的实现下看看效果，我这里用guava实现的布隆过滤器：

<dependencies> 
<dependency> 
<groupId>com.google.guava</groupId> 
<artifactId>guava</artifactId> 
<version>23.0</version> 
</dependency> 
</dependencies>

public class BloomFilterTest {

private static final int capacity = 1000000;
private static final int key = 999998;

private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), capacity);

static {
for (int i = 0; i < capacity; i++) {
bloomFilter.put(i);
}
}

public static void main(String[] args) {
/*返回计算机最精确的时间，单位微妙*/
long start = System.nanoTime();

if (bloomFilter.mightContain(key)) {
System.out.println("成功过滤到" + key);
}
long end = System.nanoTime();
System.out.println("布隆过滤器消耗时间:" + (end - start));
int sum = 0;
for (int i = capacity + 20000; i < capacity + 30000; i++) {
if (bloomFilter.mightContain(i)) {
sum = sum + 1;
}
}
System.out.println("错判率为:" + sum);
}
}

成功过滤到999998
布隆过滤器消耗时间:215518
错判率为:318
可以看到，100w个数据中只消耗了约0.2毫秒就匹配到了key，速度足够快。然后模拟了1w个不存在于布隆过滤器中的key，匹配错误率为318/10000，也就是说，出错率大概为3%，跟踪下BloomFilter的源码发现默认的容错率就是0.03：

public static <T> BloomFilter<T> create(Funnel<T> funnel, int expectedInsertions /* n */) {
return create(funnel, expectedInsertions, 0.03); // FYI, for 3%, we always get 5 hash functions
}

我们可调用BloomFilter的这个方法显式的指定误判率：

private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), capacity,0.01);

我们断点跟踪下，误判率为0.02和默认的0.03时候的区别:

对比两个出错率可以发现，误判率为0.02时数组大小为8142363，0.03时为7298440，误判率降低了0.01，BloomFilter维护的数组大小也减少了843923，可见BloomFilter默认的误判率0.03是设计者权衡系统性能后得出的值。要注意的是，布隆过滤器不支持删除操作。用在这边解决缓存穿透问题就是：

public String getByKey(String key) {
// 通过key获取value
String value = redisService.get(key);
if (StringUtil.isEmpty(value)) {
if (bloomFilter.mightContain(key)) {
value = userService.getById(key);
redisService.set(key, value);
return value;
} else {
return null;
}
}
return value;
}

(三)缓存雪崩问题

缓存在同一时间内大量键过期（失效），接着来的一大波请求瞬间都落在了数据库中导致连接异常。阿里的人说可以判断是否过期，如果过期迅速返回指定错误，服务端发现指定错误之后，立即进行相应处理，不在访问数据库

解决方案：

方案1、也是像解决缓存穿透一样加锁排队，实现同上;

方案2、建立备份缓存，缓存A和缓存B，A设置超时时间，B不设值超时时间，先从A读缓存，A没有读B，并且更新A缓存和B缓存;

方案3、设置缓存超时时间的时候加上一个随机的时间长度，比如这个缓存key的超时时间是固定的5分钟加上随机的2分钟，酱紫可从一定程度上避免雪崩问题；

public String getByKey(String keyA,String keyB) {
String value = redisService.get(keyA);
if (StringUtil.isEmpty(value)) {
value = redisService.get(keyB);
String newValue = getFromDbById();
redisService.set(keyA,newValue,31, TimeUnit.DAYS);
redisService.set(keyB,newValue);
}
return value;
}

(四)缓存并发问题

这里的并发指的是多个redis的client同时set key引起的并发问题。其实redis自身就是单线程操作，多个client并发操作，按照先到先执行的原则，先到的先执行，其余的阻塞。当然，另外的解决方案是把redis.set操作放在队列中使其串行化，必须的一个一个执行，具体的代码就不上了，当然加锁也是可以的，至于为什么不用redis中的事务，留给各位看官自己思考探究。

redis高并发需求由来

1.Redis高并发的问题

Redis缓存的高性能有目共睹，应用的场景也是非常广泛，但是在高并发的场景下，也会出现问题：缓存击穿、缓存雪崩、缓存和数据一致性，以及今天要谈到的缓存并发竞争。

这里的并发指的是多个redis的client同时set key引起的并发问题。

2.出现并发设置Key的原因

Redis是一种单线程机制的nosql数据库，基于key-value，数据可持久化落盘。由于单线程所以Redis本身并没有锁的概念，多个客户端连接并不存在竞争关系，但是利用jedis等客户端对Redis进行并发访问时会出现问题。

比如：同时有多个子系统去set一个key。这个时候要注意什么呢？

3.举一个例子

多客户端同时并发写一个key，一个key的值是1，本来按顺序修改为2,3,4，最后是4，但是顺序变成了4,3,2，最后变成了2。
在这里插入图片描述

如何解决redis的并发竞争key问题呢？下面给到2个Redis并发竞争的解决方案。

第一种方案：分布式锁+时间戳

1.整体技术方案

这种情况，主要是准备一个分布式锁，大家去抢锁，抢到锁就做set操作。

加锁的目的实际上就是把并行读写改成串行读写的方式，从而来避免资源竞争。

2.Redis分布式锁的实现

主要用到的redis函数是setnx()

用SETNX实现分布式锁

利用SETNX非常简单地实现分布式锁。例如：某客户端要获得一个名字youzhi的锁，客户端使用下面的命令进行获取：

SETNX lock.youzhi<current Unix time + lock timeout + 1>

如返回1，则该客户端获得锁，把lock.youzhi的键值设置为时间值表示该键已被锁定，该客户端最后可以通过DEL lock.foo来释放该锁。
如返回0，表明该锁已被其他客户端取得，这时我们可以先返回或进行重试等对方完成或等待锁超时。

3.时间戳

由于上面举的例子，要求key的操作需要顺序执行，所以需要保存一个时间戳判断set顺序。

系统A key 1 {ValueA 7:00}

系统B key 1 { ValueB 7:05}

假设系统B先抢到锁，将key1设置为{ValueB 7:05}。接下来系统A抢到锁，发现自己的key1的时间戳早于缓存中的时间戳（7:00<7:05），那就不做set操作了。

4.什么是分布式锁

因为传统的加锁的做法（如java的synchronized和Lock）这里没用，只适合单点。因为这是分布式环境，需要的是分布式锁。

当然，分布式锁可以基于很多种方式实现，比如zookeeper、redis等，不管哪种方式实现，基本原理是不变的：用一个状态值表示锁，对锁的占用和释放通过状态值来标识。

第二种方案：利用消息队列

在并发量过大的情况下,可以通过消息中间件进行处理,把并行读写进行串行化。

把Redis.set操作放在队列中使其串行化,必须的一个一个执行。

这种方式在一些高并发的场景中算是一种通用的解决方案。

以上就是Redis并发竞争key技术方案详解，相关的Redis高并发问题具体还可以参考：高并发架构系列：如何解决Redis雪崩、穿透、并发等5大难题

参考：高并发架构系列：Redis并发竞争key的解决方案详解

参考：Redis缓存穿透、缓存雪崩、redis并发问题分析

posted @ 2019-09-04 08:45 aspirant 阅读(4430) 评论(2) 编辑收藏举报

刷新页面返回顶部

朝北教室的风筝

用心做每一件事

Redis缓存穿透、缓存雪崩、redis并发问题并发竞争key的解决方案 (阿里)

1. 缓存穿透

1.1 什么是缓存穿透？

1.2 缓存穿透的危害

1.3 为什么会发生缓存穿透？

1.4 缓存穿透的解决方案

1.4.1 缓存空数据

1.4.2 BloomFilter

1.4.3 两种方案的比较

2. 缓存雪崩

2.1 什么是缓存雪崩？

2.2 如何避免缓存雪崩？

2.2.1 使用缓存集群，保证缓存高可用

2.2.2 使用Hystrix

3. 热点数据集中失效

3.1 什么是热点数据集中失效？

3.2 解决方案

3.2.1 互斥锁

3.3.2 设置不同的失效时间

redis高并发需求由来

公告

朝北教室的风筝

用心做每一件事

Redis缓存穿透、缓存雪崩、redis并发问题 并发竞争key的解决方案 (阿里)

1. 缓存穿透

1.1 什么是缓存穿透？

1.2 缓存穿透的危害

1.3 为什么会发生缓存穿透？

1.4 缓存穿透的解决方案

1.4.1 缓存空数据

1.4.2 BloomFilter

1.4.3 两种方案的比较

2. 缓存雪崩

2.1 什么是缓存雪崩？

2.2 如何避免缓存雪崩？

2.2.1 使用缓存集群，保证缓存高可用

2.2.2 使用Hystrix

3. 热点数据集中失效

3.1 什么是热点数据集中失效？

3.2 解决方案

3.2.1 互斥锁

3.3.2 设置不同的失效时间

redis高并发需求由来

公告

Redis缓存穿透、缓存雪崩、redis并发问题并发竞争key的解决方案 (阿里)