缓存雪崩

引入缓存的时候，我们正常是这样做的，先判断缓存是否有数据，如果有数据，从缓存返回数据，如果没有数据，则从数据库查询。流程如下：

通过缓存，我们的系统可以支持大量的并发，但是如果发生了一下事件，则会发送缓存雪崩：
1、同一时间，大量的缓存失效时间到期。
2、缓存不可用。
3、热点问题。
此时缓存是没有数据或者不可用，则大量的请求直接到数据库，数据库撑不住这么大的并发，直接崩溃。尽管一直重启数据库，还是撑不住要崩溃。
针对1的问题，我们可以对key设置一个随机值的过期时间，分散他们的过期时间。
针对2的问题，我们主要是要保证缓存的可用性，比如redis的主从，redis的哨兵，redis的集群。同时，还要保证redis的持久化，这样重启后能够快速恢复缓存里的内容。
如果没有做持久化，那启动reids的时候，大量的请求是没有缓存直接请求数据库，一样会让数据库崩溃。
针对热点问题，即便redis做了分片，但是热点的key还是只能到达指定的redis服务器，此时redis服务器如果撑不住了，就会让请求访问数据库，导致数据库崩溃。
解决方案如下：先查本地缓存，再查redis，最后查数据库。此时数据的一致性没办法做保证的，比如redis和本地缓存的不一致。本地缓存的过期时间要小于redis的过期时间，这样尽量缩小不一致的时间。流程如下：

本地缓存是存在于应用中的，应用是可以扩容的，而单点的redis是没法比扩容的，所以把压力分担到应用中，来解决热点问题