Redis常见问题

一。Key的过期淘汰机制

Redis可以对存储在Redis中的缓存数据设置过期时间，比如我们获取的短信验证码一般十分钟过期，我们这时候就需要在验证码存进Redis时添加一个key的过期时间，但是这里有一个需要格外注意的问题就是：并非key过期时间到了就一定会被Redis给删除。

定时删除

​ 设置键的过期时间，创建定时器，一旦过期时间来临，就立即对键进行操作。

缺点：

​ 这种对内存是友好的，但是对 CPU 的时间是最不友好的，特别是在业务繁忙，过期键很多的时候，删除过期键这个操作就会占据很大一部分 CPU 的时间。

​ 要知道 Redis 是单线程操作，在内存不紧张而 CPU 紧张的时候，将 CPU 的时间浪费在与业务无关的删除过期键上面，会对 Redis 的服务器的响应时间和吞吐量造成影响。

​ 另外，创建一个定时器需要用到 Redis 服务器中的时间事件，而当前时间事件的实现方式是无序链表，时间复杂度为 O(n)，让服务器大量创建定时器去实现定时删除策略，会产生较大的性能影响，所以，定时删除并不是一种好的删除策略。

惰性删除

​ 与定时删除相反，惰性删除策略对 CPU 来说是最友好的，程序只有在取出键的时候才会进行检查，是一种被动的过程。

缺点：

​ 与此同时，惰性删除对内存来说又是最不友好的，一个键过期，只要不再被取出，这个过期键就不会被删除，它占用的内存也不会被释放。

​ 很明显，惰性删除也不是一个很好的策略，Redis 是非常依赖内存和较好内存的，如果一些长期键长期没有被访问，就会造成大量的内存垃圾，甚至会操成内存的泄漏。

​ 在对执行数据写入时，通过 expireIfNeeded 函数对写入的 Key 进行过期判断。

​ 其中 expireIfNeeded 在内部做了三件事情，分别是：

	1、查看 Key 是否过期。
	2、向 Slave 节点传播执行过去 Key 的动作。
	3、删除过期 Key。

定期删除

​ 无论是定时删除和惰性删除，这两种删除方式在单一的使用上都存在明显的缺陷，要么占用太多 CPU 时间，要么浪费太多内存。

​ 定期删除策略是前两种策略的一个整合和折中：

定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的时间和频率来减少删除操作对 CPU 时间的影响。
通过合理的删除执行的时长和频率，来达到合理的删除过期键。

定期删除+惰性删除：

所谓定期删除，指的是redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。假设redis里放了10万个key，都设置了过期时间，你每隔几百毫秒，就检查10万个key，那redis基本上就死了，cpu负载会很高的，消耗在你的检查过期key上了。注意，这里可不是每隔100ms就遍历所有的设置过期时间的key，那样就是一场性能上的灾难。实际上redis是每隔100ms随机抽取一些key来检查和删除的。

定期删除：

1）定时任务在每个数据库空间随机检测20个键，当发现过期时，删除对应的键
2）如果超过检查数25%的键过期，循环执行回收逻辑直到不足25%或运行超时为止，慢模式下超时时间为25毫秒
3）如果之前回收的键逻辑超时，则在redis触发内部事件之前再次以快模式运行回收过期键任务，快模式下超时时间为1毫秒且2秒内只能运行一次
4）快慢两种模式内部删除逻辑相同，只是执行的超时时间不同。

​ 但是问题是，定期删除可能会导致很多过期key到了时间并没有被删除掉，那咋整呢？所以就是惰性删除了。这就是说，在你获取某个key的时候，redis会检查一下 ，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会给你返回任何东西。

​ 并不是key到时间就被删除掉，而是你查询这个key的时候，redis再懒惰的检查一下

​ 通过上述两种手段结合起来，保证过期的key一定会被干掉。

​ 很简单，就是说，你的过期key，靠定期删除没有被删除掉，还停留在内存里，占用着你的内存呢，除非你的系统去查一下那个key，才会被redis给删除掉。

问题：

​ 但是实际上这还是有问题的，如果定期删除漏掉了很多过期key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？如果大量过期key堆积在内存里，导致redis内存块耗尽了，怎么办？

​ 答案是：走内存淘汰机制。

内存淘汰（内存溢出控制策略）

​ 如果redis的内存占用过多的时候，此时会进行内存淘汰，有如下一些策略：

        redis 10个key，现在已经满了，redis需要删除掉5个key
        1个key，最近1分钟被查询了100次
        1个key，最近10分钟被查询了50次
        1个key，最近1个小时倍查询了1次

1）noeviction：不淘汰，当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了

2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）

3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的key给干掉啊

4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key（这个一般不太合适）

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

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

内存优化：

1、redis 实际内存消耗主要包括：建值对象、缓冲区内存、内存碎片

2 、通过调整 maxmemory 控制redis最大可用内存。当内存使用超出时，根据 maxmemory-policy 控制内存回收策略

3、内存是相对宝贵的资源，通过合理的优化可以有效的降低内存的使用量，内存优化的思路包括：

    精简键值对大小，键值字面量精简，使用高效二进制序列工具
    使用对象共享池优化小整数对象
    数据优先使用整数，比字符串类型更节省空间
    优化字符串使用，避免预分配造成的内存浪费
    使用 ziplist 压缩编码优化 hash、list等结构，注重效率和空间的平衡
    使用 intset 编码优化整合集合
    使用 ziplist 编码的 hash 结构降低减小对象链规模

对象共享：

Redis 在自己的对象系统中构建了一个引用计数方法，通过这个方法程序可以跟踪对象的引用计数信息，除了可以在适当的时候进行对象释放，还可以用来作为对象共享。

举个例子，假使键 A 创建了一个整数值 100 的字符串作为值对象，这个时候键 B 也创建保存同样整数值 100 的字符串对象作为值对象。
那么在 Redis 的操作时：

	讲数据库键的指针指向一个现有的值对象。
	讲被共享的值对象引用计数加一。

假使，我们的数据库中指向整数值 100 的键不止键 A 和键 B，而是有几百个，那么 Redis 服务器中只需要一个字符串对象的内存就可以保存原本需要几百个字符串对象的内存才能保存的数据。

缓存击穿：

​ 首先我们来看下请求是如何取到数据的：当接收到用户请求，首先先尝试从Redis缓存中获取到数据，如果缓存中能取到数据则直接返回结果，当缓存中不存在数据时从DB获取数据，如果数据库成功取到数据，则更新Redis，然后返回数据
​ 定义：高并发的情况下，某个热门key突然过期，导致大量请求在Redis未找到缓存数据，进而全部去访问DB请求数据，引起DB压力瞬间增大。

​ 因此，如果黑客每次故意查询一个在缓存内必然不存在的数据，导致每次请求都要去存储层去查询，这样缓存就失去了意义。如果在大流量下数据库可能挂掉。这就是缓存击穿。

​ 场景如下图所示:

​ 我们正常人在登录首页的时候，都是根据userID来命中数据，然而黑客的目的是破坏你的系统，黑客可以随机生成一堆userID,然后将这些请求怼到你的服务器上，这些请求在缓存中不存在，就会穿过缓存，直接怼到数据库上,从而造成数据库连接异常。

解决方案：

缓存击穿的情况下一般不容易造成DB的宕机，只是会造成对DB的周期性压力。对缓存击穿的解决方案一般可以这样：

 Redis中的数据不设置过期时间，然后在缓存的对象上添加一个属性标识过期时间，每次获取到数据时，校验对象中的过期时间属性，如果数据即将过期，则异步发起一个线程主动更新缓存中的数据。但是这种方案可能会导致有些请求会拿到过期的值，就得看业务能否可以接受，如果要求数据必须是新数据，则最好的方案则为热点数据设置为永不过期，然后加一个互斥锁保证缓存的单线程写。

使用互斥锁(mutex key)

业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

"提前"使用互斥锁(mutex key)：

在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。

---

“永远不过期”：

	这里的“永远不过期”包含两层意思：

	从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。
	从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期

资源保护:

采用netflix的hystrix，可以做资源的隔离保护主线程池，如果把这个应用到缓存的构建也未尝不可

各种方案的优缺点:

缓存穿透:

​ 定义：缓存穿透是指查询缓存和DB中都不存在的数据。比如通过id查询商品信息，id一般大于0，攻击者会故意传id为-1去查询，由于缓存是不命中则从DB中获取数据，这将会导致每次缓存都不命中数据导致每个请求都访问DB，造成缓存穿透。

解决方案：

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

	采用异步更新策略，无论key是否取到值，都直接返回。value值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热(项目启动前，先加载缓存)操作。
	
	提供一个能迅速判断请求是否有效的拦截机制，比如，利用布隆过滤器，内部维护一系列合法有效的key。迅速判断出，请求所携带的Key是否合法有效。如果不合法，则直接返回。
	
	如果从数据库查询的对象为空，也放入缓存，只是设定的缓存过期时间较短，比如设置为60秒。

缓存雪崩

定义：缓存中如果大量缓存在一段时间内集中过期了，这时候会发生大量的缓存击穿现象，所有的请求都落在了DB上，由于查询数据量巨大，引起DB压力过大甚至导致DB宕机。

解决方案：

1、给缓存的失效时间，加上一个随机值，避免集体失效。如果Redis是集群部署，将热点数据均匀分布在不同的Redis库中也能避免全部失效的问题使用互斥锁，但是该方案吞吐量明显下降了。
2、设置热点数据永远不过期。
3、双缓存
    我们有两个缓存，缓存A和缓存B。缓存A的失效时间为20分钟，缓存B不设失效时间。自己做缓存预热操作。然后细分以下几个小点:
	1. 从缓存A读数据库，有则直接返回
	2. A没有数据，直接从B读数据，直接返回，并且异步启动一个更新线程。
	3. 更新线程同时更新缓存A和缓存B。