不管我们使用的哪种缓存产品，基本上都会遇到缓存击穿、缓存失效以及热点key的问题。一旦出现上述问题，如洪水般的请求会涌向后台DB服务器，轻则应用迟缓，重则整个应用系统瘫痪。
1- 缓存并发更新控制
一个共享缓存失效后，接下来有多个线程尝试从后台数据库服务器获取数据来更新缓存时，因为只需要一个线程完成从数据库中取数据然后在放在缓存内即可，然后其他线程再去取这个缓存，并需要并发的更新这个缓存。
解决方案
使用锁机制（缓存服务器集群环境下，使用分布式锁），在缓存更新或者过期的情况下，先尝试获取到锁，当更新或者从数据库获取完成后再释放锁，其他的请求只需要牺牲一定的等待时间，即可直接从缓存中继续获取数据，效率较高。可在缓存更新方法上加上sychronized修饰。
2- 缓存击穿
也叫缓存穿透，查询一个数据库中不存在的数据，比如商品详情，查询一个不存在的ID，每次都会访问DB，可能不会被关注，但是这个却是造成数据库高负载的元凶。
解决方案
缓存空对象
当通过某一个key去查询数据的时候，如果对应在数据库中的数据都不存在，我们将此key对应的value设置为一个默认的值，比如“NULL”，并设置一个缓存的失效时间，这时在缓存失效之前，所有通过此key的访问都被缓存挡住了。后面如果此key对应的数据在DB中存在时，缓存失效之后，通过此key再去访问数据，就能拿到新的value了。这种方式实现起来成本较低，比较适合命中不高，但可能被频繁更新的数
据单独过滤处理
对所有可能对应数据为空的key进行统一的存放，并在请求前做拦截，这样避免请求穿透到后端数据库。这种方式实现起来相对复杂，比较适合命中不高，但是更新不频繁的数据。
3- 缓存颠簸
缓存的颠簸问题，有些地方可能被成为“缓存抖动”，可以看做是一种比“雪崩”更轻微的故障，但是也会在一段时间内对系统造成冲击和性能影响。一般是由于缓存节点故障导致。
解决方案
业内推荐的做法是通过一致性Hash算法来解决。
4- 热点Key
缓存中的某些Key(可能对应用与某个促销商品)对应的value存储在集群中一台机器，使得所有流量涌向同一机器，成为系统的瓶颈，该问题的挑战在于它无法通过增加机器容量来解决。
解决方案
- 客户端热点key缓存：将热点key对应value并缓存在客户端本地，并且设置一个失效时间。对于每次读请求，将首先检查key是否存在于本地缓存中，如果存在则直接返回，如果不存在再去访问分布式缓存的机器。
- 服务端负载均衡：将热点key复制多个副本，然后存储到缓存集群的不同机器上。当通过热点key去查询数据时，通过某种hash算法随机选择一个副本机器访问缓存，将热点分散到了不同机器上。
5- 缓存雪崩
缓存雪崩就是指由于缓存的原因，导致大量请求到达后端数据库，从而导致数据库崩溃，整个系统崩溃，发生灾难。
解决方法
场景1：导致这种现象的原因有很多种，上面提到的“缓存并发”，“缓存穿透”，“缓存颠簸”等问题，其实都可能会导致缓存雪崩现象发生。
根据上面的解决方法来避免雪崩的发生
场景2： 缓存冷启动或者大量缓存同时失效，例如某个时间点内，系统预加载的缓存周期性集中失效了，也可能会导致雪崩。
解决方案：
- 为了解决冷启动的问题，启动时，先预热缓存，根据实际业务估算将数据从数据库总load到缓存中，注意要分批次load，防止DB崩溃。
- 为了避免这种周期性大量缓存同时失效，可以通过设置不同的过期时间，来错开缓存过期，从而避免缓存集中失效。
