缓存雪崩现象
case1：一般是由于某个memcached节点失效，导致其他节点的缓存命中率下降，缓存中缺失的数据就需要去数据库中查询，短时间内，频繁的访问数据库导致数据库服务器承受不住那么大的请求压力而崩溃（换句话说，就是缓存失效导致短时间内访问数据库，数据库承受不住如此大的压力而被一下压垮）
重启后，因为缓存为空，数据库服务器再次被压垮，但是会向缓存中写入一些数据；
数据库服务器反复多次重启，直到缓存重建完毕，数据库服务器才能成功启动并稳定运行
case2：假设每秒1200并发,Memcached 周期每6小时失效，由于请求量过多Memcache已满，造成BD奔溃。
解决方案：
1：把缓存设置为随机3到9小时的生命周期，这样不同失效，把工作分配到各个点上去。
2：把缓存时间调长,到凌晨4-5点[人数最少的时候]去更新缓存。
解决思路：
1，采用加锁计数，或者使用合理的队列数量来避免缓存失效时对数据库造成太大的压力。这种办法虽然能缓解数据库的压力，但是同时又降低了系统的吞吐量。
2，分析用户行为，尽量让失效时间点均匀分布。避免缓存雪崩的出现。
3，如果是因为某台缓存服务器宕机，可以考虑做主备，比如：redis主备，但是双缓存涉及到更新事务的问题，update可能读到脏数据，需要好好解决。
什么是缓存穿透？
一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB）。如果key对应的value是一定不存在的，并且对该key并发请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。
总结为一句话：去查找的key在DB中不存在，每次都要去DB中查，给DB
带来巨大的压力，这就是缓存穿透。
如何避免？
1：对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该key对应的数据insert了之后清理缓存。
2：对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的Bitmap中，查询时通过该bitmap过滤。【感觉应该用的不多吧】