正常访问缓存的流程
这里以访问浏览器为例，用户访问浏览器中某一数据时，浏览器根据业务逻辑向Redis进行请求，尝试获取放在Redis中的缓存数据，如果能找到该数据，那么就将该数据直接返回而不用访问数据库。如果没有获取到该数据，那么就需要向数据库进行查询，如果能查询到数据，就将该数据返回，并将该数据写入到Redis中，从而更新缓存。
缓存雪崩
Redis中可以使用expire相关命令设定key的超时时间。
缓存雪崩指的是同一时间大量缓存的（热点）key同时失效（超时）或者Redis服务器宕机，导致缓存失效，所有的请求打向数据库，为数据库带来巨大压力，导致数据库响应不及时挂掉。
此时与该缓存以及数据库相应的业务逻辑都将失败。
那么缓存雪崩的解决方案有哪些呢？
解决方案:
- 给不同的Key的TTL（超时时间）设定为随机值
- 利用Redis集群提高服务的可用性，将这些热点key平均分配在不同的Redis节点上
- 不设置缓存失效时间（不推荐）
- 给缓存业务添加降级限流策略（不推荐）
- 开启定时任务定时刷新这些热点key的超时时间
- 给业务添加多级缓存
缓存穿透
这里还是举个例子：
依旧是访问浏览器，用户访问那些存在在Redis或者数据库中的数据的时候都能正常返回结果，但是如果查询那些不存在于Redis中也不存在于数据库中的数据，那么这些无意义的查询如果非常多，都将直接穿过Redis而导向数据库，导致数据库压力提高，造成宕机。
因此，缓存穿透就是指用户访问那些在数据库和Redis中都不存在的数据，例如我们知道id采用自增策略，那么就不可能出现负数id，而如果不法分子使用负数id进行查询，那么这些请求都会穿过Redis直接向数据库发送请求，从而导致数据库压力骤增，导致数据库宕机。（一般是恶意行为）
那么如何解决缓存穿透问题？
- 缓存空对象，每次发送这种查询不到的id的时候都把这些id缓存到Redis中，并且设定值为空（null），那么下次如果是一样的id进行查询就会直接返回空对象。
优点在于实现简单，维护容易，缺点在于内存浪费。 - 直接拉黑恶意请求的IP，对方可能不断更换IP
- 对参数合法性进行校验
- 布隆过滤器，优点在于内存占用少，不会出现多余的key，缺点在于实现不容易，并且有误判的可能
缓存击穿
缓存击穿又叫热点key问题，指的是一个被高并发访问的并且缓存重建业务较为复杂的key突然失效了，导致大量的请求瞬间打向数据库的问题。
例如一个热点key设定超时时间为1小时，结果超过了1小时之后还有源源不断的访问来请求这个热点key，而此时在Redis中的该热点key的缓存已经失效了，那么这些访问请求都将访问数据库，从而导致数据库压力骤增的情况。
那么如何解决缓存击穿问题？
- 设定该热点key时间为永不超时（不合理）
- 使用分布式锁，如果是单体应用就可以使用互斥锁
大致原理如下：
当有大量的请求访问时，如果数据能在Redis中找到，那么就直接返回，如果找不到就需要查询数据库，那么如果我们能减少同一时间向数据库发送请求的次数，就能减少数据库的压力。因此我们可以为这个热点key的查询逻辑上加上锁，那么同一时间只能有一个线程获取到这个锁，然后执行其逻辑，之后该线程再将查询到的数据重新写入Redis中，与此同时其他的线程进行等待休眠一段时间，之后再重新去Redis中进行查询，此时是能查询到数据的，那么就直接返回数据，从而减少了数据库的压力。 - 逻辑过期模式
逻辑过期模式意思是首先需要维护一个逻辑过期的字段，当时间到达过期时间之后，这个缓存数据不会直接消失，而是继续存在，此时如果有线程访问了这个数据，那么这个线程会开启一个新的线程去更新这个数据，这个时候如果有其他线程访问到了这个过期的数据，并不会等待，而是直接返回过期的数据，这样，如果某个线程在那个进行数据更新的线程完成更新之后进行查询，那么查询到的就是更新后的数据了。
这样做的好处是不会死锁，线程无需等待，性能更高，不过问题在于由于会直接返回数据，因此一致性不好，并且实现复杂，由于多维护了一个字段，因此有额外的内存消耗。
