Redis 实战篇 Part 1
😉 本文共21字，阅读时间约8min
缓存三大问题
缓存穿透
问题
缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，数据库的并发不如redis那么高，带来巨大压力。
解决方案
常见的解决方案有两种：
- 缓存空对象
- 哪怕这个数据在数据库中也不存在，我们也把这个数据存入到redis中去，这样，下次用户过来访问这个不存在的数据，那么在redis中也能找到这个数据就不会进入到缓存了。
- 优点：实现简单
- 缺点：额外的内存消耗、可能造成短期的不一致
- 布隆过滤
- 优点：内存占用较少，没有多余key
- 缺点：实现复杂：在不一定在，但不在一定不在。存在误判可能。
布隆过滤器其实采用的是哈希思想来解决这个问题，通过一个庞大的二进制数组，走哈希思想去判断当前这个要查询的这个数据是否存在。
如果布隆过滤器判断这个数据不存在，则直接返回。如果布隆过滤器判断存在，则放行。
缓存雪崩
问题
缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，数据库的并发不如redis那么高，带来巨大压力。
解决方案
- 给不同的Key的TTL添加随机值
- 利用Redis集群提高服务的可用性
- 给业务添加多级缓存
- 给缓存业务添加降级限流策略
缓存击穿
问题
缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。
假设线程1在查询缓存之后，本来应该去查询数据库，然后把这个数据重新加载到缓存的，但是假设在线程1因为构建复杂没有走完的时候。
后续的线程2，线程3，线程4同时过来访问当前这个方法， 那么这些线程都不能从缓存中查询到数据，那么他们就会同一时刻来访问查询缓存，都没查到，接着同一时间去访问数据库，同时的去执行数据库代码，对数据库访问压力过大。
常见的解决方案有两种：
- 互斥锁
- 逻辑过期
互斥锁
- 查询缓存命中则直接返回
- 未命中，则setnx加锁
- 加锁成功，则构建缓存
- 加锁失败，则阻塞一会儿再重试。
逻辑过期
- 逻辑过期：我们之所以会出现这个缓存击穿问题，主要原因是在于我们对key设置了过期时间，假设我们不设置过期时间，其实就不会有缓存击穿的问题。
- 我们把过期时间设置在 redis的value中，注意：这个过期时间并不会直接作用于redis，而是我们后续通过逻辑去处理。
- 假设线程1去查询缓存，然后从value中判断出来当前的数据已经过期了，此时线程1去获得互斥锁，那么其他线程会进行阻塞。获得了锁的线程他会新开启一个 线程去进行以前的重构数据的逻辑，直到新开的线程完成这个逻辑后，才释放锁，
- 而线程1直接进行返回
- 假设现在线程3过来访问，由于线程线程2持有着锁，所以线程3无法获得锁，线程3也直接返回数据，只有等到新开的线程2把重建数据构建完后，其他线程才能走返回正确的数据。
这种方案巧妙在于，异步的构建缓存，缺点在于在构建完缓存之前，返回的都是脏数据。
