缓存设计

缓存击穿

缓存穿透是指查询一个根本不存在的数据， 缓存层和存储层都不会命中， 通常出于容错的考虑， 如果从存储 层查不到数据则不写入缓存层。缓存穿透将导致不存在的数据每次请求都要到存储层去查询， 失去了缓存保护后端存储的意义。

• 原因：
  1. 第一， 自身业务代码或者数据出现问题。
  2. 第二， 一些恶意攻击、 爬虫等造成大量空命中。
• 解决方法
  1. 将没有命中的key也用空值放入缓存中，设置过期时间。
  2. 布隆过滤器
     对于恶意攻击，向服务器请求大量不存在的数据造成的缓存穿透，还可以用布隆过滤器先做一次过滤，对于不 存在的数据布隆过滤器一般都能够过滤掉，不让请求再往后端发送。当布隆过滤器说某个值存在时，这个值可 能不存在;当它说不存在时，那就肯定不存在。布隆过滤器就是一个大型的位数组和几个不一样的无偏 hash 函数。所谓无偏就是能够把元素的 hash 值算得 比较均匀。向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash 算得一个整数索引值然后对位数组长度 进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位置。再把位数组的这几个位置都置为 1 就 完成了 add 操作。向布隆过滤器询问 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出来，看看位数组中这几个位 置是否都为 1，只要有一个位为 0，那么说明布隆过滤器中这个key 不存在。如果都是 1，这并不能说明这个 key 就一定存在，只是极有可能存在，因为这些位被置为 1 可能是因为其它的 key 存在所致。如果这个位数组 比较稀疏，这个概率就会很大，如果这个位数组比较拥挤，这个概率就会降低。这种方法适用于数据命中不高、 数据相对固定、 实时性低(通常是数据集较大) 的应用场景， 代码维护较为 复杂， 但是缓存空间占用很少。

缓存失效

由于大批量缓存在同一时间失效可能导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大 甚至挂掉，对于这种情况我们在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个时间段内的不同 时间。

缓存雪崩

缓存雪崩指的是缓存层支撑不住或宕掉后， 流量会像奔逃的野牛一样， 打向后端存储层。 由于缓存层承载着大量请求， 有效地保护了存储层， 但是如果缓存层由于某些原因不能提供服务(比如超大并 发过来，缓存层支撑不住，或者由于缓存设计不好，类似大量请求访问bigkey，导致缓存能支撑的并发急剧下 降)， 于是大量请求都会达到存储层， 存储层的调用量会暴增， 造成存储层也会级联宕机的情况。

• 预防和解决缓存雪崩问题， 可以从以下三个方面进行着手。
  1. 保证缓存层服务高可用性，比如使用Redis Sentinel或Redis Cluster。
  2. 依赖隔离组件为后端限流并降级。比如使用Hystrix限流降级组件。
  3. 提前演练。 在项目上线前， 演练缓存层宕掉后， 应用以及后端的负载情况以及可能出现的问题， 在此基 础上做一些预案设定。

热点缓存key重建优化

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

• 当前key是一个热点key(例如一个热门的娱乐新闻)，并发量非常大。
• 重建缓存不能在短时间完成， 可能是一个复杂计算， 例如复杂的SQL、 多次IO、 多个依赖等。
  在缓存失效的瞬间， 有大量线程来重建缓存， 造成后端负载加大， 甚至可能会让应用崩溃。 要解决这个问题主要就是要避免大量线程同时重建缓存。 我们可以利用互斥锁来解决，此方法只允许一个线程重建缓存， 其他线程等待重建缓存的线程执行完， 重新从 缓存获取数据即可。

开发规范与性能优化

键值设计

• key名设计：以业务名(或数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表名:id
• 保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视
• 不要包含特殊字符：空格、换行、单双引号以及其他转义字符

value设计

• 拒绝bigkey(防止网卡流量、慢查询)在Redis中，一个字符串最大512MB，一个二级数据结构(例如hash、list、set、zset)可以存 储大约40亿个(2^32-1)个元素，但实际中如果下面两种情况，我就会认为它是bigkey。
  1. 字符串类型:它的big体现在单个value值很大，一般认为超过10KB就是bigkey。
  2. 非字符串类型:哈希、列表、集合、有序集合，它们的big体现在元素个数太多。
     一般来说，string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。 反例:一个包含200万个元素的list。 非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注 意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，造 成阻塞)

bigkey的危害

• 导致redis阻塞
• 网络拥塞
  bigkey也就意味着每次获取要产生的网络流量较大，假设一个bigkey为1MB，客户端每秒访问 量为1000，那么每秒产生1000MB的流量，对于普通的千兆网卡(按照字节算是128MB/s)的服务 器来说简直是灭顶之灾，而且一般服务器会采用单机多实例的方式来部署，也就是说一个bigkey 可能会对其他实例也造成影响，其后果不堪设想。
• 过期删除 ：有个bigkey，它安分守己(只执行简单的命令，例如hget、lpop、zscore等)，但它设置了过 期时间，当它过期后，会被删除，如果没有使用Redis 4.0的过期异步删除(lazyfree-lazy- expire yes)，就会存在阻塞Redis的可能性。

bigkey的产生

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

• 社交类:粉丝列表，如果某些明星或者大v不精心设计下，必是bigkey。
• 统计类:例如按天存储某项功能或者网站的用户集合，除非没几个人用，否则必是bigkey。
• 缓存类:将数据从数据库load出来序列化放到Redis里，这个方式非常常用，但有两个地方需 要注意，第一，是不是有必要把所有字段都缓存;第二，有没有相关关联的数据，有的同学为了 图方便把相关数据都存一个key下，产生bigkey。

如何优化bigkey

1. 拆
   big list: list1、list2、...listN
   big hash:可以讲数据分段存储，比如一个大的key，假设存了1百万的用户数据，可以拆分成 200个key，每个key下面存放5000个用户数据
2. 如果bigkey不可避免，也要思考一下要不要每次把所有元素都取出来(例如有时候仅仅需要 hmget，而不是hgetall)，删除也是一样，尽量使用优雅的方式来处理。
3. 选择适合的数据类型。 例如:实体类型(要合理控制和使用数据结构，但也要注意节省内存和性能之间的平衡)
4. 控制key的生命周期，redis不是垃圾桶。建议使用expire设置过期时间(条件允许可以打散过期时间，防止集中过期)。

命令使用

1.【推荐】 O(N)命令关注N的数量
例如hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明确N的值。有 遍历的需求可以使用hscan、sscan、zscan代替。
2.【推荐】:禁用命令
禁止线上使用keys、flushall、flushdb等，通过redis的rename机制禁掉命令，或者使用scan的 方式渐进式处理。
3.【推荐】合理使用select redis的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还 是单线程处理，会有干扰。
4.【推荐】使用批量操作提高效率

 1 原生命令:例如mget、mset。
 2 非原生命令:可以使用pipeline提高效率。
原生是原子操作，pipeline是非原子操作。
pipeline可以打包不同的命令，原生做不到
pipeline需要客户端和服务端同时支持。

5.【建议】Redis事务功能较弱，不建议过多使用，可以用lua替代

客户端使用

1.【推荐】避免多个应用使用一个Redis实例 正例:不相干的业务拆分，公共数据做服务化。
2.【推荐】使用带有连接池的数据库，可以有效控制连接，同时提高效率。

Redis对于过期键有三种清除策略

• 被动删除:当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过
  期key。
• 主动删除:由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰
  一批已过期的key
• 当前已用内存超过maxmemory限定时，触发主动清理策略当REDIS运行在主从模式时，只有主结点才会执行被动和主动这两种过期删除策略，然后把删除 操作”del key”同步到从结点。

第三种策略的情况如下:

当前已用内存超过maxmemory限定时，会触发主动清理策略 根据自身业务类型，选好maxmemory-policy(最大内存淘汰策略)，设置好过期时间。如果不设 置最大内存，当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)， 会让 Redis 的性能急剧下降。默认策略是volatile-lru，即超过最大内存后，在过期键中使用lru算法进行key的剔除，保证不过 期数据不被删除，但是可能会出现OOM问题。

• 其他策略如下:
  1. allkeys-lru:根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间 为止。
  2. allkeys-random:随机删除所有键，直到腾出足够空间为止。
  3. volatile-random: 随机删除过期键，直到腾出足够空间为止。
  4. volatile-ttl:根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction策略。
  5. noeviction:不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error) OOM command not allowed when used memory"，此时Redis只响应读操作。