Redis——雪崩、穿透、击穿等问题

1. 缓存穿透

• 解释：缓存穿透是指查询⼀个缓存中⼀定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写⼊缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，失去了缓存的意义，造成缓存穿透。
  • 例如：有人查询id为-1的数据，并且请求频率很大，因为缓存中没有每次都需要执行sql，并发情况下容易造成服务器出现问题，造成一定的损失。
• 解决方案：
  • 缓存空对象：如果⼀个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进⾏缓存，但它的过期时间会很短，最⻓不超过五分钟。
    • 缓存空对象带来的问题
      • 1： 空值做了缓存，意味着缓存中存了更多的键，需要更多的内存空间，⽐较有效的⽅法是针对这类数据设置⼀个较短的过期时间，让其⾃动剔除
      • 2： 缓存和存储的数据会有⼀段时间窗⼝的不⼀致，可能会对业务有⼀定影响。例如：过期时间设置为 5分钟，如果此时存储添加了这个数据，那此段时间就会出现缓存和存储数据的不⼀致，此时可以利⽤消息系统或者其他⽅式清除掉缓存层中的空对象，就涉及到了数据同步的问题。

2.缓存击穿

• 解释： 缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。
• 解决方案：
  • 设置热点数据永远不过期。
  • 接口限流与熔断，降级 。重要的接口一定要做好限流策略，防止用户恶意刷接口，同时要降级准备，当接口中的某些 服务 不可用时候，进行熔断，失败快速返回机制
  • 推荐一篇大佬写的缓存击穿解决方案

3.缓存雪崩

• 解释：指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
• 解决方案：
  • 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
  • 如果缓存数据库是分布式部署，将热点数据均匀分布在不同的缓存数据库中。
  • 设置热点数据永远不过期
  • 使用多级缓存机制，比如同时使用redsi和memcache缓存，请求->redis->memcache->db
  • 购买第三方可靠性高的Redis云服务器

4.缓存和数据库双写一致性问题

你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？

• 从理论上说，只要我们设置了合理的键的过期时间，我们就能保证缓存和数据库的数据最终是⼀致的。因为只要缓存数据过期了，就会被删除。随后读的时候，因为缓存⾥没有，就可以查数据库的数据，然后将数据库查出来的数据写⼊到缓存中。除了设置过期时间，我们还需要做更多的措施来尽量避免数据库与缓存处于不⼀致的情况发⽣。
• 新增、更改、删除数据库操作时同步更新 Redis，可以使⽤事物机制来保证数据的⼀致性。
• 推荐两篇具体描述的文章
  缓存一致性
  缓存一致性

5.并发竞争 Key 问题

• 解释：所谓 Redis 的并发竞争 Key 的问题也就是多个系统同时对一个 key 进行操作，但是最后执行的顺序和我们期望的顺序不同，这样也就导致了结果的不同！
  推荐一种方案：分布式锁（zookeeper 和 redis 都可以实现分布式锁）。（如果不存在 Redis 的并发竞争 Key 问题，不要使用分布式锁，这样会影响性能）
  基于zookeeper临时有序节点可以实现的分布式锁。大致思想为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。完成业务流程后，删除对应的子节点释放锁。
  在实践中，当然是从以可靠性为主。所以首推Zookeeper