在研读关于缓存相关的文章过程中，发现和缓存冷启动以及缓存预热这几点还讲解的可以，虽然说的有点笼统，但是方案大致还算明白了，以下为摘录内容，可以研读。

1.缓存冷启动以及缓存预热解决方案

当系统第一次启动，大量请求涌入，此时的缓存为空，可能会导致DB崩溃，进而让系统不可用，同样当redis所有缓存数据异常丢失，也会导致该问题。因此，可以提前放入数据到redis避免上述冷启动的问题，当然也不可能是全量数据，可以根据类似于当天的具体访问情况，实时统计出访问频率较高的热数据，这里热数据也比较多，需要多个服务并行的分布式去读写到redis中（所以要基于zk分布式锁）

通过nginx+lua将访问流量上报至kafka中，storm从kafka中消费数据，实时统计处每个商品的访问次数，访问次数基于LRU（apache commons collections LRUMap）内存数据结构的存储方案，使用LRUMap去存放是因为内存中的性能高，没有外部依赖，每个storm task启动的时候基于zk分布式锁将自己的id写入zk同一个节点中，每个storm task负责完成自己这里的热数据的统计，每隔一段时间就遍历一下这个map，然后维护一个前1000的数据list，然后去更新这个list，最后开启一个后台线程，每隔一段时间比如一分钟都将排名的前1000的热数据list同步到zk中去，存储到这个storm task对应的一个znode中去

部署多个实例的服务，每次启动的时候就会去拿到上述维护的storm task id列表的节点数据，然后根据taskid，一个一个去尝试获取taskid对应的znode的zk分布式锁，如果能够获取到分布式锁，再去获取taskid status的锁进而查询预热状态，如果没有被预热过，那么就将这个taskid对应的热数据list取出来，从而从DB中查询出来写入缓存中，如果taskid分布式锁获取失败，快速抛错进行下一次循环获取下一个taskid的分布式锁即可，此时就是多个服务实例基于zk分布式锁做协调并行的进行缓存的预热

2.缓存热点导致系统不可用解决方案

对于瞬间大量的相同数据的请求涌入，可能导致该数据经过hash策略之后对应的应用层nginx被压垮，如果请求继续就会影响至其他的nginx，最终导致所有nginx出现异常整个系统变得不可用。

基于nginx+lua+storm的热点缓存的流量分发策略自动降级来解决上述问题的出现，可以设定访问次数大于后95%平均值n倍的数据为热点，在storm中直接发送http请求到流量分发的nginx上去，使其存入本地缓存，然后storm还会将热点对应的完整缓存数据没发送到所有的应用nginx服务器上去，并直接存放到本地缓存。对于流量分发nginx，访问对应的数据，如果发现是热点标识就立即做流量分发策略的降级，对同一个数据的访问从hash到一台应用层nginx降级成为分发至所有的应用层nginx。storm需要保存上一次识别出来的热点List，并同当前计算出来的热点list做对比，如果已经不是热点数据，则发送对应的http请求至流量分发nginx中来取消对应数据的热点标识

3.缓存雪崩解决方案

redis集群彻底崩溃，缓存服务大量对redis的请求等待，占用资源，随后缓存服务大量的请求进入源头服务去查询DB，使DB压力过大崩溃，此时对源头服务的请求也大量等待占用资源，缓存服务大量的资源全部耗费在访问redis和源服务无果，最后使自身无法提供服务，最终会导致整个网站崩溃。

事前的解决方案，搭建一套高可用架构的redis cluster集群，主从架构、一主多从，一旦主节点宕机，从节点自动跟上，并且最好使用双机房部署集群。

事中的解决方案，部署一层ehcache缓存，在redis全部实现情况下能够抗住部分压力；对redis cluster的访问做资源隔离，避免所有资源都等待，对redis cluster的访问失败时的情况去部署对应的熔断策略，部署redis cluster的降级策略；对源服务访问的限流以及资源隔离

事后的解决方案：redis数据做了备份可以直接恢复，重启redis即可；redis数据彻底失败来或者数据过旧，可以快速缓存预热，然后让redis重新启动。然后由于资源隔离的half-open策略发现redis已经能够正常访问，那么所有的请求将自动恢复

作者：java高级分享
链接：https://juejin.cn/post/6844903558404374541
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。