Redis缓存设计、bigkey及key过期策略

1.缓存穿透

缓存穿透是指查询一个根本不存在的数据， 缓存层和存储层都不会命中， 通常出于容错的考虑， 如果从存储层查不到数据则不写入缓存层。

造成缓存穿透的原因：

1）自身业务代码或数据出现问题；

2）恶意攻击、爬虫等造成大量空命中。

解决方案：

1）缓存空对象；

2）使用布隆过滤器过滤。

布隆过滤器是由一个位图（位数组）和不一样的无偏hash函数组成。（无偏指的是哈希比较均匀）

在查找某个key是否存在时，首先通过几个hash函数把该key位于位图上的几个位置算出来，如果这些位置都为1，那这个key极有可能存在；如果有位置为0，那这个key必然不存在。

注意：布隆过滤器不能删除数据，如果要删除，得重新初始化数据。（因为多次哈希散列的远呀）

适用场景：这种方法适用于数据命中不高、 数据相对固定、 实时性低（通常是数据集较大） 的应用场景， 代码维护较为复杂， 但是缓存空间占用很少。

2.缓存击穿（失效）

由于大批量缓存在同一时间失效可能导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大甚至挂掉。

解决方案：在批量增加缓存时，将这一批数据的缓存过期时间设置为一个时间段内的不同时间（增加短暂的随机时间）。

3.缓存雪崩

缓存雪崩指的是缓存层支撑不住或者宕掉时，非常多的流量打到后端存储层。

造成原因：超大并发过来，缓存层支撑不住，或者由于缓存设计不好，类似大量请求访问bigkey，导致缓存能支撑的并发急剧下降，从而导致缓存层不能提供服务，于是大量请求都会打到存储层，存储层的调用量会暴增， 可能造成存储层级联宕机的情况。

预防和解决方案：

1）保证缓存层服务高可用性，使用集群，比如使用Redis Sentinel或Redis Cluster。

2）依赖隔离组件为后端限流熔断并降级。

比如服务降级，我们可以针对不同的数据采取不同的处理方式。当业务应用访问的是非核心数据（例如电商商品属性，用户信息等）时，暂时停止从缓存中查询这些数据，而是直接返回预定义的默认降级信息、空值或是错误提示信息；当业务应用访问的是核心数据（例如电商商品库存）时，仍然允许查询缓存，如果缓存缺失， 也可以继续通过数据库读取。

3）提前演练。 在项目上线前， 演练缓存层宕掉后， 应用以及后端的负载情况以及可能出现的问题， 在此基础上做一些预案设定。

4.热点缓存key的重建优化

开发人员使用“缓存+过期时间”的策略既可以加速数据读写， 又保证数据的定期更新， 这种模式基本能够满足绝大部分需求。 但是有两个问题如果同时出现， 可能就会对应用造成致命的危害：

1. 当前key是一个热点key（例如一个热门的娱乐新闻），并发量非常大。
2. 重建缓存不能在短时间完成， 可能是一个复杂计算， 例如复杂的SQL、 多次IO、 多个依赖等。

在缓存失效的瞬间， 有大量线程来重建缓存， 造成后端负载加大， 甚至可能会让应用崩溃。

要解决这个问题主要就是要避免大量线程同时重建缓存。

我们可以利用互斥锁来解决，此方法只允许一个线程重建缓存， 其他线程等待重建缓存的线程执行完， 重新从缓存获取数据即可。

5.缓存与数据库双写不一致

在高并发下，同时操作数据库与缓存会存在数据不一致的问题。

1.双写不一致的问题：

线程1先写数据库，线程2后写数据库，但是线程2比线程1更早更新缓存，最终导致缓存中线程1的数据覆盖了线程2的数据，和我们预期的结果不一致（预期数据为线程2的数据）。

2.读写并发不一致：

线程1删掉缓存后，线程3查缓存为空，然后线程3查数据库，然后线程3更新了缓存，此时缓存的数据和我们预期的数据不一致（预期数据为线程2的6）。

解决方案：

1、对于并发几率很小的数据(如个人维度的订单数据、用户数据等)，这种几乎不用考虑这个问题，很少会发生缓存不一致，可以给缓存数据加上过期时间，每隔一段时间触发读的主动更新即可。

2、就算并发很高，如果业务上能容忍短时间的缓存数据不一致(如商品名称，商品分类菜单等)，缓存加上过期时间依然可以解决大部分业务对于缓存的要求。

3、如果不能容忍缓存数据不一致，可以通过加分布式读写锁保证并发读写或写写的时候按顺序排好队，读读的时候相当于无锁。

4、也可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存，但是引入了新的中间件，增加了系统的复杂度。

总结：以上我们针对的都是读多写少的情况加入缓存提高性能，如果写多读多的情况又不能容忍缓存数据不一致，那就没必要加缓存了，可以直接操作数据库。

当然，如果数据库抗不住压力，还可以把缓存作为数据读写的主存储，异步将数据同步到数据库，数据库只是作为数据的备份。 放入缓存的数据应该是对实时性、一致性要求不是很高的数据。切记不要为了用缓存，同时又要保证绝对的一致性做大量的过度设计和控制，增加系统复杂性！

6.bigkey问题

6.1bigkey是什么？

实际中如果存在下面两种情况之一，我就会认为它是bigkey：

1. 字符串类型：它的big体现在单个value值很大，一般认为超过10KB就是bigkey。
2. 非字符串类型：哈希、列表、集合、有序集合，它们的big体现在元素个数太多。

一般来说，string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。

对于非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞）

6.2bigkey的危害

1.导致redis阻塞

2.网络拥塞

bigkey也就意味着每次获取要产生的网络流量较大，假设一个bigkey为1MB，客户端每秒访问量为1000，那么每秒产生1000MB的流量，对于普通的千兆网卡(按照字节算是128MB/s)的服务器来说简直是灭顶之灾，而且一般服务器会采用单机多实例的方式来部署，也就是说一个bigkey可能会对其他实例也造成影响，其后果不堪设想。

3.过期删除

有个bigkey，它安分守己（只执行简单的命令，例如hget、lpop、zscore等），但它设置了过期时间，当它过期后，会被删除，如果没有使用Redis 4.0的过期异步删除(lazyfree-lazy-expire yes)，就会存在阻塞Redis的可能性。

6.3bigkey的产生

一般来说，bigkey的产生都是由于程序设计不当，或者对于数据规模预料不清楚造成的，来看几个例子：

(1) 社交类：粉丝列表，如果某些明星或者大v不精心设计下，必是bigkey。

(2) 统计类：例如按天存储某项功能或者网站的用户集合，除非没几个人用，否则必是bigkey。

(3) 缓存类：将数据从数据库load出来序列化放到Redis里，这个方式非常常用，但有两个地方需要注意，第一，是不是有必要把所有字段都缓存；第二，有没有相关关联的数据，有的同学为了图方便把相关数据都存一个key下，产生bigkey。

6.4优化方案

1.拆分大key

比如，将一个list拆分成多个list；比如一个大的key，假设存了1百万的用户数据，可以拆分成

200个key，每个key下面存放5000个用户数据。

2.如果bigkey不可避免：（1）在用的时候思考一下要不要每次把所有元素都取出来(例如有时候仅仅需要

hmget，而不是hgetall)，删除也是一样，尽量使用优雅的方式来处理。（2）使用合理的数据类型。

3.控制key的生命周期，redis不是垃圾桶。 【推荐】

建议使用expire设置过期时间(条件允许可以打散过期时间，防止集中过期)。

7.key过期清除策略

1.被动删除：当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过期的key；

2.主动删除：由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰一批已过期的key。如果当前已用内存超过maxmemory限定时，触发主动清理策略。

7.1内存淘汰策略

1.针对设置了过期时间的key的处理：

• volatile-ttl：在筛选时，会针对设置了过期时间的键值对，根据过期时间的先后进行删除，越早过期的越先被删除。
• volatile-random：就像它的名称一样，在设置了过期时间的键值对中，进行随机删除。
• volatile-lru：会使用 LRU 算法筛选设置了过期时间的键值对删除。
• volatile-lfu：会使用 LFU 算法筛选设置了过期时间的键值对删除。

2.针对所有key的处理：

• allkeys-random：从所有键值对中随机选择并删除数据。
• allkeys-lru：使用 LRU 算法在所有数据中进行筛选删除。
• allkeys-lfu：使用 LFU 算法在所有数据中进行筛选删除

3.不处理：

noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error)，此时Redis只响应读操作。

7.2推荐使用volatile-LRU

当存在热点数据时，LRU的效率很好，但偶发性的、周期性的批量操作会导致LRU命中率急剧下降，缓存污染情况比较严重。这时使用LFU可能更好点。

根据自身业务类型，配置好maxmemory-policy(默认是noeviction)，推荐使用volatile-lru。如果不设置最大内存，当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)，会让 Redis 的性能急剧下降。

当Redis运行在主从模式时，只有主结点才会执行过期删除策略，然后把删除操作”del key”同步到从结点删除数据。