Redis缓存存在的三个问题及其解决方式

击穿

为什么会有击穿

• Key的过期

• LRU、LFU导致Key已被移除

如何解决

分布式锁

分布式锁的问题

• 设置锁的Redis挂了：设置锁的过期时间

• 没挂但是锁时间太短导致超时锁失效，后续线程新设置了一把锁进到数据库

  继续使用多线程：线程1去数据库取数据，线程2每隔一段时间如果更新锁过期时间

  但是这样就导致了客户端代码量增多

所以我们自己实现分布式协调挺麻烦的。看后续有了ZooKeeper怎么帮我们解决这些分布式协调的问题的。

穿透

为什么会有穿透

从业务接收的查询是你的系统根本不存在的数据，这样别说在Redis中没有，在MySQL中照样没有，

但是如果没有控制方式，还是不断会有各种请求打到数据库中。

如何解决

站在布隆后面！

1. 客户端包含布隆过滤器

   要求比较大的客户端存储

   但是省去了部分Redis的请求压力

2. 布隆过滤器的BitMap存在Redis中

3. Redis集成布隆过滤器

问题：

有误伤概率

不支持删除

其余过滤器

布谷鸟过滤器：听说支持删除，但是算法没有深究

雪崩

为什么会有雪崩

大量的Key同时击穿，造成大量的访问到达数据库

如何解决

1. 如果数据要求必须到整点过期(比如凌晨24:00)

   单个Key击穿怎么解决，就只能挨个来了

2. 数据时点性无关，随机过期时间即可

3. 既然我们已经知道了数据时点性这么强，挑个用户量最少的时候，是在没办法就只能24:00的话，业务服务直接休眠1秒，在业务线程休眠的时刻，定时任务去负责加载数据到Redis

分布式锁

Redis设置分布式锁

setnx()

• 设置锁的服务器挂了：

  【解决方案】设置锁的过期时间

• 没挂但是锁时间太短导致超时锁失效，后续线程新设置了一把锁进到数据库

  【解决方案】继续使用多线程：线程1去数据库取数据，线程2每隔一段时间如果更新锁过期时间。但是这样就导致了客户端代码量增多

ZooKeeper分布式协调

客户端创建临时节点，并发情况下，有临时节点时不再创建新的临时节点。

ZK会自己保持与客户端心跳，如果没完成业务客户端就已经挂机，则临时节点消失，其他客户端重新设置临时节点

而且支持Watch回调机制，可以实现队列形式的锁！