redis第五第六章-redis并发缓存架构和性能优化

一、缓存设计

1.缓存穿透

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

造成缓存穿透的基本原因有两个：
第一， 自身业务代码或者数据出现问题。
第二， 一些恶意攻击、 爬虫等造成大量空命中。

缓存穿透问题解决方案：
（1）缓存空对象，并且对这个缓存设置一个过期时间

（2）布隆过滤器
对于恶意攻击，向服务器请求大量不存在的数据造成的缓存穿透，还可以用布隆过滤器先做一次过滤，对于不存在的数据布隆过滤器一般都能够过滤掉，不让请求再往后端发送。当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。

布隆过滤器就是一个大型的位数组和几个不一样的无偏 hash 函数。所谓无偏就是能够把元素的 hash 值算得比较均匀。
向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash 算得一个整数索引值然后对位数组长度进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位置。再把位数组的这几个位置都置为 1 就完成了 add 操作。
向布隆过滤器询问 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出来，看看位数组中这几个位置是否都为 1，只要有一个位为 0，那么说明布隆过滤器中这个key 不存在。如果都是 1，这并不能说明这个key 就一定存在，只是极有可能存在，因为这些位被置为 1 可能是因为其它的 key 存在所致。如果这个位数组比较稀疏，这个概率就会很大，如果这个位数组比较拥挤，这个概率就会降低。
这种方法适用于数据命中不高、 数据相对固定、 实时性低（通常是数据集较大） 的应用场景， 代码维护较为复杂， 但是缓存空间占用很少。

其核心代码如上，首先通过redisson创建一个布隆过滤器，起一个名字，最主要的是设置这个过滤器的大小，实际要看业务场景，看你的redis要缓存多少数据，然后设置一个误差率，因为布隆过滤器并不能完美的过滤出不存在的key。
然后将要缓存的数据key存入到布隆过滤器里，之后就相当于对集合进行判断元素是否存在了！
注意：使用布隆过滤器需要把所有数据提前放入布隆过滤器，并且在增加数据时也要往布隆过滤器里放；
布隆过滤器不能删除数据，如果要删除得重新初始化数据。

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

对于缓存击穿来说，一般解决方法大概两个：
第一个就是对大批量的缓存再设置一个随机的过期时间，让这些key不要瞬间失效；
第二个就是加分布式锁，当一个线程拿到锁获得数据之后，将数据缓存到redis里，其余线程就会去redis能够获取到了

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

预防和解决缓存雪崩问题， 可以从以下三个方面进行着手。
1） 保证缓存层服务高可用性，比如使用Redis Sentinel或Redis Cluster。
2） 依赖隔离组件为后端限流熔断并降级。比如使用Sentinel或Hystrix限流降级组件。
比如服务降级，我们可以针对不同的数据采取不同的处理方式。当业务应用访问的是非核心数据（例如电商商品属性，用户信息等）时，暂时停止从缓存中查询这些数据，而是直接返回预定义的默认降级信息、空值或是错误提示信息；当业务应用访问的是核心数据（例如电商商品库存）时，仍然允许查询缓存，如果缓存缺失，也可以继续通过数据库读取。
3） 提前演练。 在项目上线前， 演练缓存层宕掉后， 应用以及后端的负载情况以及可能出现的问题， 在此基础上做一些预案设定。

2.热点缓存key重建优化

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

• 当前key是一个热点key（例如一个热门的娱乐新闻，或者一件商品突然访问量变大了，比如疫情的板蓝根），并发量非常大
• 重建缓存不能在短时间完成， 可能是一个复杂计算， 例如复杂的SQL、 多次IO、 多个依赖等。

在缓存失效的瞬间， 有大量线程来重建缓存， 造成后端负载加大， 甚至可能会让应用崩溃。
要解决这个问题主要就是要避免大量线程同时重建缓存。
我们可以利用互斥锁（读写锁）来解决，此方法只允许一个线程重建缓存， 其他线程等待重建缓存的线程执行完， 重新从缓存获取数据即可。

3.缓存和数据库数据不一致的情况

1. 双写不一致情况

解释：当线程1更新了数据库，此时因为网络或者业务逻辑等各种原因，还没有更新缓存，这时线程2也更新了这条数据，并且更新了缓存，最后线程1才更新了缓存，这样就会出现数据不一致的情况

2. 读写并发不一致
   
   解释：当线程1更新了数据，同时删除了缓存，此时线程3查询缓存，发现没有数据，因为线程1已经删除了缓存，那么线程3就会查数据库，同时想要更新缓存，但因为各种原因如网络波动、业务逻辑等原因，卡住了，此时线程2更新了这条数据，同时删除缓存，但线程3还是把旧的数据更新到缓存里了

解决方案：
1、对于并发几率很小的数据(如个人维度的订单数据、用户数据等)，这种几乎不用考虑这个问题，很少会发生缓存不一致，可以给缓存数据加上过期时间，每隔一段时间触发读的主动更新即可。
2、就算并发很高，如果业务上能容忍短时间的缓存数据不一致(如商品名称，商品分类菜单等)，缓存加上过期时间依然可以解决大部分业务对于缓存的要求。
3、如果不能容忍缓存数据不一致，可以通过加分布式读写锁保证并发读写或写写的时候按顺序排好队，读读的时候相当于无锁。
4、也可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存，但是引入了新的中间件，增加了系统的复杂度。
总结：

• 引入缓存是为了提高性能，上面的方案也都是读多写少的情况，要是出现读多写多这种情况，又不能接收缓存不一致的情况，就完全没必要用缓存了，这不是吃饱了撑的吗？
• 当然，如果数据库抗不住压力，还可以把缓存作为数据读写的主存 储，异步将数据同步到数据库，数据库只是作为数据的备份。
• 放入缓存的数据应该是对实时性、一致性要求不是很高的数据。切记不要为了用缓存，同时又要保证绝对的一致性做大量的过度设计和控制，增加系统复杂性！

4.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。

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

bigkey的危害：

• 1.导致redis阻塞

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

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

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

如何优化bigkey

1. 拆
   big list： list1、list2、…listN
   big hash：可以讲数据分段存储，比如一个大的key，假设存了1百万的数据，可以拆分成200个key，每个key下面存放5000个数据量
2. 如果bigkey不可避免，也要思考一下要不要每次把所有元素都取出来(例如有时候仅仅需要hmget，而不是hgetall)，删除也是一样，尽量使用优雅的方式来处理。
3. 【推荐】：控制key的生命周期，redis不是垃圾桶。 建议使用expire设置过期时间(条件允许可以打散过期时间，防止集中过期)。

5.redis连接池的使用

使用带有连接池的数据库，可以有效控制连接，同时提高效率，标准使用方式：


1）maxTotal：最大连接数

2）maxIdle和minIdle

解释：maxTotal：100 maxIdle：20 minIdle：10

• redis线程池是个懒加载的过程，只有在用的时候才会创建连接，同时将连接放到线程池中
• 当需要创建连接时最大的线程池是100，当执行完成之后，会逐步释放线程池连接，恢复到20个连接，只要当特殊配置的时候，才会释放到10个连接，一般都会以maxIdle为准；
• 但minIdle还有个作用：就是方便线程池预热
• 如果系统启动完马上就会有很多的请求过来，那么可以给redis连接池做预热，比如快速的创建一些redis连接，执行简单命令，类似ping()，快速的将连接池里的空闲连接提升到minIdle的数量。

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

1. 被动删除：当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过期key
2. 主动删除：由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰一批已过期的key
3. 当前已用内存超过maxmemory限定时，触发主动清理策略

主动清理策略在Redis 4.0 之前一共实现了 6 种内存淘汰策略，在 4.0 之后，又增加了 2 种策略，总共8种：

LRU 算法（Least Recently Used，最近最少使用）
淘汰很久没被访问过的数据，以最近一次访问时间作为参考。
LFU 算法（Least Frequently Used，最不经常使用）
淘汰最近一段时间被访问次数最少的数据，以次数作为参考。

根据自身业务类型，配置好maxmemory-policy(默认是noeviction)，推荐使用volatile-lru。
如果不设置最大内存，当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)，会让 Redis 的性能急剧下降。
当Redis运行在主从模式时，只有主结点才会执行过期删除策略，然后把删除操作”del key”同步到从结点删除数据。