缓存冷启动问题

缓存冷启动：

　　1.新系统第一次上线，此时在缓存里可能是没有数据的

　　2.系统在线上稳定运行着，但是突然间重要的redis缓存全盘崩溃了，而且不幸的是，数据全都无法找回来

　　系统第一次上线启动，系统在redis故障的情况下重新启动，对于一个流量很大的系统来说，在高并发的场景下，大量的请求很容易击穿数据库。

 

缓存预热（采用storm、kafka）

　　由于缓存冷启动，redis启动后，一点数据都没有，直接就对外提供服务了，mysql就裸奔

　　（1）提前给redis中灌入部分数据，再提供服务
　　（2）如果数据量非常大，就不可能将所有数据都写入redis，因为数据量太大了，第一是因为耗费的时间太长了，第二根本redis容纳不下所有的数据
　　（3）需要根据当天的具体访问情况，实时统计出访问频率较高的热数据
　　（4）然后将访问频率较高的热数据写入redis中，肯定是热数据也比较多，我们也得多个服务并行读取数据去写，并行的分布式的缓存预热
　　（5）然后将灌入了热数据的redis对外提供服务，这样就不至于冷启动，直接让数据库裸奔了

 

缓存预热解决方案：

对于商品详情页：

1.将访问流量上报到kafka中

　　要统计出来当前最新的实时的热数据是哪些，我们就得将请求的数据实时上报到kafka中

2.storm从kafka中消费数据，实时统计出每个请求数据的访问次数，访问次数基于LRU内存数据结构的存储方案

　　优先用内存中的一个LRUMap去存放，因为它的性能高，而且没有外部依赖，如果存放redis就会依赖redis，我们就是要防止redis挂掉数据丢失的情况，就不合适了; 用mysql，扛不住高并发读写; 用hbase，hadoop生态系统，维护麻烦，太重了

其实我们只要统计出最近一段时间访问最频繁的商品，然后对它们进行访问计数，同时维护出一个前N个访问最多的商品list即可

　　获取热数据，如：最近一段时间，可以拿到最近一段，比如最近1个小时，最近5分钟，1万个商品请求，统计出最近这段时间内每个商品的访问次数，排序，做出一个排名前N的list

　　计算好每个task大致要存放的商品访问次数的数量，计算出大小

　　然后构建一个LRUMap，apache commons collections有开源的实现，设定好map的最大大小，就会自动根据LRU算法去剔除多余的数据，保证内存使用限制

　　即使有部分数据被干掉了，然后下次来重新开始计数，也没关系，因为如果它被LRU算法干掉，那么它就不是热数据，说明最近一段时间都很少访问了

3.每个storm task启动的时候，基于zk分布式锁，将自己的id写入zk同一个节点中

4.每个storm task负责完成自己这里的热数据的统计，每隔一段时间，就遍历一下这个map，然后维护一个前3个商品的list，更新这个list

5.写一个后台线程，每隔一段时间，比如1分钟，都将排名前20的热数据list，同步到zk中去，存储到这个storm task对应的一个znode中去

　　每次服务启动的时候，就会去拿到一个storm task的列表，然后根据taskid，一个一个的去尝试获取taskid对应的znode的zk分布式锁

　　如果能获取到分布式锁的话，那么就将那个storm task对应的热数据的list取出来

　　然后将数据从mysql中查询出来，写入缓存中，进行缓存的预热，多个服务实例，分布式的并行的去做，基于zk分布式锁做了协调了，分布式并行缓存的预热