redis应用问题及解决

redis应用问题解决

1、缓存穿透

当系统中引入redis缓存后，一个请求进来后，会先从redis缓存中查询，缓存有就直接返回，缓存中没 有就去数据库中查询，数据库中如果有就会将其丢到缓存中，但是有些key对应更多数据在数据库中并不存在，每次 针对此次key的请求从缓存中取不到，请求都会压到数据库，从而可能压垮数据库。

也就是说，请求的数据缓存中不存在，数据库中同样不存在。

1.1、解决方案

1. 对空值缓存

   如果一个查询返回的数据为空（不管数据库是否存在），我们仍然把这个结果（null）进行缓存，给其 设置一个很短的过期时间，最长不超过五分钟。

2. 设置可访问的白名单

   使用redis中的bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次范文和 bitmap里面的id进行比较，如果访问的id不在bitmaps里面，则进行拦截，不允许访问。

3. 采用布隆过滤

   布隆过滤器实际上是一个很长的二进制向量（位图）和一系列随机映射函数（哈希函数）。 布隆过滤器可以用于检测一个元素是否在一个集合中，它的优点是空间效率和查询的世界都远远超过一 般的算法，缺点是有一定的误识别率和删除困难。将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被这个bitmaps拦截 掉，从而避免了对底层存储系统的查询压力。

4. 进行实时监控

   当发现redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名 单限制对其提供服务（比如：IP黑名单）。

2、缓存击穿

redis中某个热点key（访问量很高的key）过期，此时大量请求同时过来（高并发访问），发现缓存中没有命中，这些请求都打到数据库上了，导致数据库压力瞬时大增，可能会打垮数据库，这种情况成为缓存击穿。

缓存击穿也就是指缓存中没有数据，数据库有数据,大量请求同时访问同一条数据。

出现缓存击穿时的现象：

• 数据库访问压力瞬时增大
• redis里面没有出现大量的key过期
• redis正常运行

2.1、解决方案

1. 预先设置热门数据，适时调整过期时间

   在redis高峰之前，把一些热门数据提前存入到redis里面，对缓存中的这些热门数据进行监控，实时调整过期时间。

2. 使用锁

   缓存中拿不到数据的时候，此时不是立即去数据库中查询，而是去获取分布式锁（比如redis中的setnx），拿到锁再去数据库中l获取数据；没有拿到锁的线程休眠一段时间再重试整个获取数据的方法。

   或者使用双重检测锁，在同步锁外面查询一次缓存，在同步锁里面再查询一次缓存。

3、缓存雪崩

key对应的数据存在，但是极短时间内有大量的key集中过期，此时若有大量的并发请求过来，发现缓存没有数据，大量的请求就会落到数据库上去加载数据，会将数据库击垮，导致服务奔溃。

缓存雪崩与缓存击穿的区别在于：前者是大量的key集中过期，而后者是某个热点key过期。

3.1、解决方案

1. 构建多级缓存

   nginx缓存+redis缓存+其他缓存（ehcache等）

2. 使用锁或队列

   用加锁或者队列的方式来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上，不适用高并发情况。

3. 监控缓存过期，提前更新

   监控缓存，发现缓存快过期了，提前对缓存进行更新。

4. 将缓存失效时间分散开

   比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样缓存的过期时间重复率就会降低，就很难引发集体失效的事件。也就是设置随机过期时间

4、分布式锁

随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多 进程且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力，为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题。

4.1、分布式锁主流的实现方案

1. 基于数据库实现分布式锁
2. 基于缓存（redis等）
3. 基于zookeeper

每一种分布式锁解决方案都有各自的优缺点

1. 性能：redis最高
2. 可靠性：zookeeper最高

此处使用redis实现分布式锁

4.2、使用redis实现分布式锁

使用命令：

# 当key不存在的时候，设置其值为value，且同时设置其有效期
set key value NX PX 有效期(毫秒)

# 例如设置当msg不存在时，值为ok，10000毫秒有效
set msg "ok" NX PX 10000

1. 上锁过程

   如图所示，执行 set key value NX PX 有效期(毫秒) 命令，返回ok表示执行成功，则获取锁成功， 多个客户端并发执行此命令的时候，redis可确保只有一个可以执行成功。

2. 设置过期时间的原因

   客户端获取锁后，由于系统问题，如系统宕机了，会导致锁无法释放，其他客户端就无法或锁了，所以 需要给锁指定一个使用期限。

3. 如果设置的有效期太短怎么办？

   比如有效期设置了10秒，但是10秒不够业务方使用，这种情况客户端需要实现续命的功能，可以解决这 个问题。

4. 解决锁误删的问题

   锁存在误删的情况：所谓误删就是自己把别人持有的锁给删掉了。

   比如线程A获取锁的时候，设置的有效期是10秒，但是执行业务的时候，A程序突然卡主了超过了10秒， 此时这个锁就可能被其他线程拿到，比如被线程B拿到了，然后A从卡顿中恢复了，继续执行业务，业务 执行完毕之后，去执行了释放锁的操作，此时A会执行del命令，此时就出现了锁的误删，导致的结果就 是把B持有的锁给释放了，然后其他线程又会获取这个锁。

   解决方法： 获取锁的之前，生成一个全局唯一id，将这个id也丢到key对应的value中，释放锁之前，从redis中将这 个id拿出来和本地的比较一下，看看是不是自己的id，如果是的再执行del释放锁的操作。

5. 总结

   为了确保分布式锁可用，我们至少需要确保分布式锁的实现同时满足以下四个条件

   • 互斥性，在任意时刻只能有一个客户端能够持有锁
   • 不糊发生死锁，即使有一个客户端在持有锁期间崩溃而没有释放锁，也能够保证后续其他客户端能够加锁
   • 解锁还需寄铃人，加锁和解锁必须是同一个客户端，客户端不能把别人的锁给解了
   • 加锁和解锁必须有原子性