雪崩：大量key同时失效 击穿：大量请求的某个key失效 穿透：缓存和数据库都不存在

• 缓存没有过期时间资源耗尽
  –过期时间

• 大量数据同时设置缓存，那么会同时失效，此时会击穿数据库 （缓存击穿（巧记：只打穿了缓存））
  –过期时间随机
  –失效后再被请求可在延时一段时间失效

• 有个数据数据库也被干掉了，大量请求过来后，穿透缓存和数据库（缓存穿透巧记：缓存和数据库都被穿‘透’了）
  –数据库没查到，设置一个短时间过期的‘空的业务数据’到缓存中
  –布隆过滤器

• 突发性热点缓存重建导致系统压力暴增（例如：冷门商品321上连接大量请求到缓存没有查到，同时去查数据库，又同时设置缓存（缓存重建））
  –提前缓存（但是要提前预知热点数据 难预知、例如热搜）
  –重建缓存时加锁（但是锁中要先查一遍缓存，DCL机制）

String cache = redisUtil.get("xxx:xxx:key");if(Objects.noNull(cache)) {if(EMPTY_CACHE.equals(cache)) {//空业务数据return null;}return JsonUtil.parse(cache);}synchronized(this) {//再次查询缓存，DCL机制String cache = redisUtil.get("xxx:xxx:key");if(Objects.noNull(cache)) {if(EMPTY_CACHE.equals(cache)) {//空业务数据return null;}return JsonUtil.parse(cache);}Object = dataDao.selectForDB(key);if(Objects.noNull(cache)) {redisUtil.set(key, json.tojsonstr(), );} else {//业务空数据redisUtil.set(key, json.tojsonstr(), );}}	

• 加锁的对象有问题，this一般是对应Service的单例，性能极其低，所以应该以资源id为锁
  –Map对象资源池去做锁（内存泄露问题，jvm级别的）
  –分布式锁setnx

• 缓存双写不一致
  –设置、更新 缓存数据时，也去加分布式锁（设置说明肯定是查询了没有才设置哦，所以这个就是让查询和更新串行了）

• 串行性能低，咋搞（一般都是读多写少的）
  –分布式读写锁，不阻塞读线程