1.缓存雪崩
缓存挂了，所有的流量一下子都打到了数据库。紧接着数据库崩了，重启数据库又会被新的流量打崩了。
缓存雪崩的事前事中事后的解决方案如下：
- 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。
- 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。
- 事后：Redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。
用户发送一个请求，系统 A 收到请求后，先查本地 ehcache 缓存，如果没查到再查 Redis。如果 ehcache 和 Redis 都没有，再查数据库，将数据库中的结果，写入 ehcache 和 Redis 中。
限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，怎么办？走降级！可以返回一些默认的值，或者友情提示，或者空值。
好处：
- 数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。
- 只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。
- 只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来了。
2.缓存穿透
有大量查询是无效的，缓存没有，数据库也没有，导致所有查询都直接查到了数据库
解决方式很简单，首先在接口判断请求值的合法性，如果不合法直接拒绝。如果合法，每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN 。然后设置一个过期时间，这样的话，下次有相同的 key 来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。
曾经被问到的一个问题：
如果数据库的id并不是按照一定顺序递增的，而黑客从1开始遍历数据库，怎么办？
这时候可以使用布隆过滤器。布隆过滤器是一种比较独特数据结构，有一定的误差。当它指定一个数据存在时，它不一定存在，但是当它指定一个数据不存在时，那么它一定是不存在的。
将数据库有效id加入布隆过滤器，如果不存在过滤器里，直接拒绝掉。
缓存空数据与布隆过滤器的比较
- 当一些恶意攻击查询查询的key各不相同，而且数量巨多，此时缓存空数据不是一个好的解决方案。因为它需要存储所有的Key，内存空间占用高。并且在这种情况下，很多key可能只用一次，所以存储下来没有意义。所以对于这种情况而言，使用布隆过滤器是个不错的选择；
- 而对与空数据的Key数量有限、Key重复请求效率较高的场景而言，可以选择缓存空数据的方案。
3.缓存击穿
某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库.
不同场景下的解决方式可如下：
- 若缓存的数据是基本不会发生更新的，则可尝试将该热点数据设置为永不过期。
- 若缓存的数据更新不频繁，且缓存刷新的整个流程耗时较少的情况下，则可以采用基于 Redis、zookeeper 等分布式中间件的分布式互斥锁，或者本地互斥锁以保证仅少量的请求能请求数据库并重新构建缓存，其余线程则在锁释放后能访问到新缓存。
- 若缓存的数据更新频繁或者在缓存刷新的流程耗时较长的情况下，可以利用定时线程在缓存过期前主动地重新构建缓存或者延后缓存的过期时间，以保证所有的请求能一直访问到对应的缓存。