Redis总结

本文围绕以下几点进行阐述

1、为什么使用redis
2、使用redis有什么缺点
3、单线程的redis为什么这么快
4、redis的数据类型，以及每种数据类型的使用场景
5、redis的过期策略以及内存淘汰机制
6、redis和数据库双写一致性问题
7、如何应对缓存穿透和缓存雪崩问题
8、如何解决redis的并发竞争问题

 

正文

1.为什么使用redis

分析：博主觉得在项目中使用redis，主要是从两个角度去考虑:性能和并发。当然，redis还具备可以做分布式锁等其他功能，但是如果只是为了分布式锁这些其他功能，完全还有其他中间件(如zookpeer等)代替，并不是非要使用redis。因此，这个问题主要从性能和并发两个角度去答。

 

2.使用redis有什么缺点

分析：大家用redis这么久，这个问题是必须要了解的，基本上使用redis都会碰到这些问题，常见的也就这四个问题

1）缓存和数据库双写一致性的问题

2）缓存雪崩的问题

3）缓存击穿的问题

4）缓存的并发竞争的问题

这四个问题，我个人是觉得在项目中，比较常遇见的，具体解决方案，后文给出

3.redis的过期策略以及内存淘汰机制

分析：这个问题其实相当重要，到底redis有没有用到家，这个问题就可以看出来。比如你redis只能存5G数据，可是你写了10G，那会删除5G的数据，怎么删除的？这个问题思考过没，还有，你的数据已经设置了过期时间，但是时间到了，内存占用率还是比较高，有思考过原因么？

解答：

 

3.redis采用的是定期删除+惰性删除策略

为什么不用定时删除策略？

定时删除，用一个定时器来负责监视key，过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源，在大并发请求下，CPU要将时间应用在处理请求，而不是删除key，因此没有采用这一策略

定期删除+惰性删除是如何工作的呢？

定期删除：redis默认每隔100ms检查，是否有过期的key，有过期的key则删除，需要说明的是，redis不是每隔100ms将所有的key检查一次，而是随机抽取进行检查（如果每隔100ms，全部key进行检查，redis可能会卡死）。因此，如果只采用定时删除策略，会导致很多key到时间了没有被删除。

惰性删除：惰性删除也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会被删除。

 

采用定期删除+惰性删除就没有其他问题了么？

不是的，如果定期删除没删除key。然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高，那么就应该采用内存淘汰机制。

在redis.conf中有一行配置 （# maxmemory-policy volatile-lru）

1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错，应该没有人这样用吧。

2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。推荐使用，目前项目在用这种。

3）allkeys-random：当内存不足以纳入新写入数据时，在键空间中，随机移除某个key。应该也没有人用吧，你不删最少使用key，去随机删。

4）volatile-lru：当内存不足以纳入新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key，这种情况一般是把redis既当缓存，又做持久化存储的时候才使用，不推荐

5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key，依然不推荐

6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除，不推荐

 

4.redis和数据库双写一致性问题

分析:一致性问题是分布式常见问题，还可以再分为最终一致性和强一致性。数据库和缓存双写，就必然会存在不一致的问题。答这个问题，先明白一个前提。就是如果对数据有强一致性要求，不能放缓存。我们所做的一切，只能保证最终一致性。另外，我们所做的方案其实从根本上来说，只能说降低不一致发生的概率，无法完全避免。因此，有强一致性要求的数据，不能放缓存。首先，采取正确更新策略，先更新数据库，再删缓存。其次，因为可能存在删除缓存失败的问题，提供一个补偿措施即可，例如利用消息队列。

 

5.如何应对缓存穿透和缓存雪崩问题

分析:这两个问题，说句实在话，一般中小型传统软件企业，很难碰到这个问题。如果有大并发的项目，流量有几百万左右。这两个问题一定要深刻考虑。

回答:如下所示

缓存穿透，即黑客故意去请求缓存中不存在的数据，导致所有的请求都怼到数据库上，从而数据库连接异常。

解决方案:

1）利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库。没得到锁，则休眠一段时间重试

2）采用异步更新策略，无论key是否取到值，都直接返回。value值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热(项目启动前，先加载缓存)操作。

3）提供一个能迅速判断请求是否有效的拦截机制，比如，利用布隆过滤器，内部维护一系列合法有效的key。迅速判断出，请求所携带的Key是否合法有效。如果不合法，则直接返回。

 

缓存雪崩，即缓存同一时间大面积的失效，这个时候又来了一波请求，结果请求都怼到数据库上，从而导致数据库连接异常。

解决方案:

1）给缓存的失效时间，加上一个随机值，避免集体失效。

2）使用互斥锁，但是该方案吞吐量明显下降了。

3）双缓存。我们有两个缓存，缓存A和缓存B。缓存A的失效时间为20分钟，缓存B不设失效时间。自己做缓存预热操作。然后细分以下几个小点

• I 从缓存A读数据库，有则直接返回

• II A没有数据，直接从B读数据，直接返回，并且异步启动一个更新线程。

• III 更新线程同时更新缓存A和缓存B。