对于高并发的业务场景，常用的技术手段包括黑白名单、限流防刷、熔断降级、兜底、线程隔离、多级缓存（客户端、CDN、NGINX、内存缓存、分布式缓存）等等。这些手段相互结合，才能应对高并发场景下的各种细分场景。本文总结了缓存方案需要考虑的几个问题。

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

第二，关于缓存并发，是指一个缓存如果失效，可能出现多个进程同时查询DB，同时设置缓存的情况。对此，可以使用三种方案：分布式锁、消息队列和永不过期。其中消息队列需要考虑数据一致性和实效性问题，而永不过期则需要考虑数据的预热以及数据的更新。

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

第四，关于缓存抖动，一般是指由于某个缓存节点故障导致该节点上的缓存数据不可用。对此，绝大部分的技术博客都会说使用一致性哈希来解决，个人认为这个说法并不准确。

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

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

第六、关于缓存双写一致性问题，是指数据写入请求需要写数据库并更新缓存，需要处理双写的一致性问题。给出以下三种策略：

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

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

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

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