缓存穿透、缓存并发、缓存雪崩、缓存抖动、热点缓存、缓存双写一致性等问题

第一，关于缓存穿透

是指大量访问缓存和数据库中都不存在的数据。对此，可以考虑使用参考博客1和2中提到的两种方案：缓存空对象（对应key数量有限、key重复请求概率较高的场景）和布隆过滤器（对应key各不相同、key重复请求概率低的场景），或者两者同时使用。

第二，关于缓存并发

是指一个缓存如果失效，可能出现多个进程同时查询DB，同时设置缓存的情况。对此，可以考虑使用参考博客2和参考博客4中提到的三种方案：分布式锁、消息队列和永不过期。其中消息队列是指不允许直接连接数据库进行查询，在缓存服务器向数据库发起的请求处理全部都要使用队列。需要考虑数据一致性和实效性问题，而永不过期则需要考虑数据的预热以及数据的更新。

第三，关于缓存雪崩

是指某一时刻大量缓存同时失效，导致请求全部打到DB。可以采用三种方案：缓存过期时间随机化、多级缓存（不同级别缓存对应不同的失效时间）、缓存永不过期；

第四，关于缓存抖动

一般是指由于某个缓存节点故障导致该节点上的缓存数据不可用。对此，绝大部分的技术博客都会说使用一致性哈希来解决，个人认为这个说法并不准确。本人的另一篇博客分析了一致性哈希和哈希槽的使用场景对比：以Redis为例，Redis集群采用哈希槽的机制，当集群内某个主节点宕机之后，其它主节点会从宕机主节点的复制节点中选取一个节点作为该槽段的新主节点。也就是说，Redis集群的抖动不是通过一致性哈希来解决的。再以Memocache为例，原生的Memocache不支持集群方式，它的集群机制是由访问它的客户端来实现的。客户端使用一致性哈希算法，将多台Memocache机器维护成一个缓存集群，当单台服务器宕机之后，该节点的缓存数据将由其它节点来承担（需要引入虚拟节点）。

第五，关于热点缓存

是指在某个特定的时间点，某些key会成为访问的热点。如参考博客5为例，短时间内，如果大量用户同时访问一个热点缓存，即使使用Redis作为缓存也可能因为无法响应这么大的流量而导致请求打到数据库，从而导致数据库崩溃。对此，参考博客4～6分别给出解决方案，共三种：第一，依赖Redis 4.0及以上版本的功能，通过LFU机制发现热点数据，并定期更新到内存缓存；第二，基于流式计算统计热点数据，并基于ZooKeeper等系统更新到内存缓存；第三，利用Redis的集合功能，基于LRU-K算法发现并缓存热点数据，也可以定期将热点数据更新到内存缓存。相比之下，方案一和方案三无需依赖外部流式计算系统，成本较低。

第六、关于缓存双写一致性问题

是指数据写入请求需要写数据库并更新缓存，需要处理双写的一致性问题。参考博客8对比了以下三种策略：

先更新数据库，再更新缓存

先删除缓存，再更新数据库

先更新数据库，再删除缓存

以最大限度避免数据不一致或者降低数据不一致的时长为目标，对比结果为：推荐使用策略3，即先更新数据库，再删除缓存。而对于数据库更新成功，而缓存删除失败，则有两种解决方案：一是key过期机制；二是基于mq重试。