前言：用户的数据一般都存储到数据库中，数据库的数据是存储在磁盘上的，当用户的请求特别多时，数据库就很容易进行崩溃，所以为了直接避免用户直接访问数据库，都会用redis作为缓存层。
具体原因：
因为redis是内存数据库，我们可以将数据库的缓存在redis中，内存的读写速度比磁盘的读写速度快好几个数量级，这样大大提高了系统性能。
缓存雪崩
简言而之就是大量缓存数据同时过期或者redis故障。
通常我们为了保证数据库的数据与缓存的数据库一致，会给Redis里的数据设置过期时间，当缓存数据过期后，用户访问的数据如果不在缓存里，业务系统需要重新生成缓存，因此就会访问数据库，并将数据更新到redis，这样后续请求直接命中缓存。
大量缓存数据同时过期或者redis故障，大量的请求会直接访问数据库，从而导致数据库压力骤增，严重造成数据库宕机，从而造成系统崩溃。这就是缓存雪崩。
1.大量数据同时过期
均匀设置过期时间
如果要给一个缓存数据设置过期时间，应避免将大量数据设置成同一个过期时间，我们可以在对缓存数据设置过期时间时，给这些数据加上一个随机数。
互斥锁
当业务线程在处理用户请求时，如果发现访问的数据不在 Redis 里，就加个互斥锁，保证同一时间内只有一个请求来构建缓存（从数据库读取数据，再将数据更新到 Redis 里），当缓存构建完成后，再释放锁。未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。实现互斥锁的时候，最好设置超时时间，不然第一个请求拿到了锁，然后这个请求发生了某种意外而一直阻塞，一直不释放锁，这时其他请求也一直拿不到锁，整个系统就会出现无响应的现象。
后台更新缓存
业务线程不再负责更新缓存，缓存也不设置有效期，而是让缓存“永久有效”，并将更新缓存的工作交由后台线程定时更新。
注意事项
缓存数据不设置有效期，并不是意味着数据一直能在内存里，当系统内存资源紧张时，有些缓存数据会被淘汰。因此有如下两种解决方式：
1.后台线程不仅负责定时更新缓存，而且也负责频繁检测缓存是否有效。
2.在业务线程发现缓存数据失效后（缓存数据被淘汰），通过消息队列发送一条消息通知后台线程更新缓存，后台线程收到消息后，在更新缓存前可以判断缓存是否存在，存在就不执行更新缓存操作；不存在就读取数据库数据，并将数据加载到缓存。
2.redis故障宕机
服务熔断或请求限流机制
一句话总结：redis故障后，暂停所有的应用对缓存服务的访问，直接返回错误。
构建 Redis 缓存高可靠集群
一句话总结：redis故障后，主从复制启动副本节点。
缓存穿透
简言而之就是某个热点数据过期了，此时大量请求访问·该热点数据就无法从缓存中读取，直接俄访问数据库。
可以发现缓存击穿跟缓存雪崩很相似，你可以认为缓存击穿是缓存雪崩的一个子集。
应对缓存击穿可以采取前面说到两种方案：
• 互斥锁方案，保证同一时间只有一个业务线程更新缓存，未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。
• 不给热点数据设置过期时间，由后台异步更新缓存，或者在热点数据准备要过期前，提前通知后台线程更新缓存以及重新设置过期时间
缓存击穿
简言而之就是大量访问数据库中不存在的数据，数据库压力骤增，这就是缓存穿透的问题。
缓存穿透的发生一般有两种：
1.业务误操作，缓存中的数据和数据库中的数据都被误删了，所以导致缓存和数据库都没有数据。
2.黑客恶意攻击，故意访问大量不存在的数据。
1.非法请求的限制
当有大量恶意请求访问不存在的数据的时候，也会发生缓存穿透，因此在 API 入口处我们要判断求请求参数是否合理，请求参数是否含有非法值、请求字段是否存在，如果判断出是恶意请求就直接返回错误，避免进一步访问缓存和数据库。
2.缓存空值或默认值
当我们线上业务发现缓存穿透的现象时，可以针对查询的数据，在缓存中设置一个空值或者默认值，这样后续请求就可以从缓存中读取到空值或者默认值，返回给应用，而不会继续查询数据库。
3.布隆过滤器
我们可以在写入数据库数据时，使用布隆过滤器做个标记，然后在用户请求到来时，业务线程确认缓存失效后，可以通过查询布隆过滤器快速判断数据是否存在，如果不存在，就不用通过查询数据库来判断数据是否存在。即使发生了缓存穿透，大量请求只会查询 Redis 和布隆过滤器，而不会查询数据库，保证了数据库能正常运行，Redis 自身也是支持布隆过滤器的。
总结
缓存异常会面临三个问题：缓存击穿，穿透，雪崩。
其中击穿与雪崩是因为数据不在缓存中了，压力给到数据库从而导致系统崩溃。
穿透是因为大量查询数据库不存在的数据，从而导致系统崩溃。
