高并发缓存面临的问题

1. 缓存问题

a. 缓存并发更新控制

场景：
一个共享缓存失效后，接下来有多个线程尝试从后台数据库服务器获取数据来更新缓存时，因为只需要一个线程完成从数据库中取数据然后在放在缓存内即可，然后其他线程再去取这个缓存，并需要并发的更新这个缓存。

解决办法：
使用锁机制（缓存服务器集群环境下，使用分布式锁），在缓存更新或者过期的情况下，先尝试获取到锁，当更新或者从数据库获取完成后再释放锁，其他的请求只需要牺牲一定的等待时间，即可直接从缓存中继续获取数据，效率较高。可在缓存更新方法上加上sychronized修饰。

b. 缓存击穿

场景：
查询一个数据库中不存在的数据，比如商品详情，查询一个不存在的ID，每次都会访问DB，造成数据库高负载

解决办法：

1. 缓存空对象，适合命中不高，但可能被频繁更新的数据，当通过某一个key去查询数据的时候，如果对应在数据库中的数据都不存在，我们将此key对应的value设置为一个默认的值，比如“NULL”，并设置一个缓存的失效时间，这时在缓存失效之前，所有通过此key的访问都被缓存挡住了。后面如果此key对应的数据在DB中存在时，缓存失效之后，通过此key再去访问数据，就能拿到新的value了

2. 单独过滤处理， 适合命中不高，但是更新不频繁的数据，对所有可能对应数据为空的key进行统一的存放，并在请求前做拦截，这样避免请求穿透到后端数据库

c. 缓存颠簸

场景：
缓存的颠簸问题，有时也会变成“缓存抖动”，在一段时间内对系统造成冲击和性能影响，一般是由于缓存节点故障导致

解决办法：
业内推荐的做法是通过一致性Hash算法来解决。

d. 热点Key

场景：
缓存中的某些Key(如促销商品或营销活动)对应的value存储在集群中一台机器，使得所有流量涌向同一机器，成为系统的瓶颈

解决办法：

1. 客户端热点key缓存：将热点key对应value并缓存在客户端本地，并且设置一个失效时间。对于每次读请求，将首先检查key是否存在于本地缓存中，如果存在则直接返回，如果不存在再去访问分布式缓存的机器
2. 服务端负载均衡：将热点key复制多个副本，然后存储到缓存集群的不同机器上。当通过热点key去查询数据时，通过某种hash算法随机选择一个副本机器访问缓存，将热点分散到了不同机器上

e. 缓存雪崩

缓存雪崩就是指由于缓存的原因，导致大量请求到达后端数据库，从而导致数据库崩溃，整个系统崩溃，发生灾难

场景1：“缓存并发”，“缓存穿透”，“缓存颠簸”等问题，导致缓存雪崩现象发生

解决办法：使用锁机制、缓存空对象、一致性哈希算法等来解决

场景2：
缓存冷启动或者大量缓存同时失效，例如某个时间点内，系统预加载的缓存周期性集中失效了，也可能会导致雪崩。

解决办法：
为了解决冷启动的问题，启动时，先预热缓存，根据实际业务估算将数据从数据库总load到缓存中，注意要分批次load，防止DB崩溃。
为了避免这种周期性大量缓存同时失效，可以通过设置不同的过期时间，来错开缓存过期，从而避免缓存集中失效。