如何设计一个多级缓存系统？

所谓多级缓存系统，就是指在一个系统的不一样的架构层级进行数据缓存，以提高访问效率。
 

咱们都知道，一个缓存系统，它面临着许多问题，好比缓存击穿，缓存穿透，缓存雪崩，缓存热点等等问题，那么，对于一个多级缓存系统，它有什么问题呢？
 

有以下几个：
缓存热点：多级缓存系统大多应用在高并发场景下，因此咱们须要解决热点 Key 问题，如何探测热点 Key？
数据一致性：各层缓存之间的数据一致性问题，如应用层缓存和分布式缓存以前的数据一致性问题。
缓存过时：缓存数据能够分为两大类，过时缓存和不过时缓存？如何设计，如何设计过时缓存？
 

整个多级缓存系统被分为三层：
应用层 Nginx 缓存
分布式 Redis 缓存集群
Tomcat 堆内缓存
 

整个架构流程以下：当接收到一个请求时，首先会分发到 Nginx 集群中，这里能够采用 Nginx 的负载均衡算法分发给某一台机器，使用轮询能够下降负载，或者采用一致性 Hash 算法来提高缓存命中率。
 

当 Nginx 层没有缓存数据时，会继续向下请求，在分布式缓存集群中查找数据，若是缓存命中，直接返回（而且写入 Nginx 应用缓存中），若是未命中，则回源到 Tomcat 集群中查询堆内缓存。
 

在分布式缓存中查询不到数据，将会去 Tomcat 集群中查询堆内缓存，查询成功直接返回（并写入分 Redis 主集群中），查询失败请求数据库；堆内缓存。
 

若是以上缓存中都没有命中，则直接请求数据库，返回结果，同步数据到分布式缓存中。
 

在简单了解了多级缓存的基本架构以后，咱们就该思考如何解决上面提到的一系列问题。
 

缓存热点
 

缓存热点，是一个很常见的问题，好比“某某明星宣布结婚”等等，均可能产生大量请求访问的问题，一个最麻烦也是最容易让人忽视的事情就是如何探测到热点 Key。
 

在缓存系统中，除了一些经常使用的热点 Key 外，在某些特殊场合下也会出现大量的热点 Key，咱们该如何发现呢？
 

有如下策略：
数据调研。能够分析历史数据以及针对不一样的场合去预测出热点 Key，这种方式虽然不能百分百使得缓存命中，可是倒是一种最简单和节省成本的方案。
实时计算。可使用现有的实时计算框架，好比 Storm、Spark Streaming、Flink 等框架统计一个时间段内的请求量，从而判断热点 Key。或者也能够本身实现定时任务去统计请求量。
 

这里咱们着重讨论一下第二种解决方案，对于热点 Key 问题，当缓存系统中没有发现缓存时，须要去数据库中读取数据。
 

当大量请求来的时候，一个请求获取锁去请求数据库，其余阻塞，接着所有去访问缓存，这样可能由于一台服务器撑不住从而宕机。
 

好比正常一台服务器并发量为 5W 左右，产生热点 Key 的时候达到了 10W 甚至 20W，这样服务器确定会崩。因此咱们在发现热点 Key 以后还须要作到如何自动负载均衡。

结合以上问题咱们从新设计架构，以下图所示：

咱们将整个应用架构分为：
应用层
分布式缓存
系统层
数据层
 

在应用层，咱们采用 Nginx 集群，而且对接实时计算链路，经过 Flume 监控 Nginx 日志，将数据传输到 Kafka 集群中，而后 Flink 集群消费数据进行统计。
 

若是统计结果为热点 Key，则将数据写入 Zookeeper 的节点中，而应用系统经过监控 Znode 节点，读取热点 Key 数据，去数据库中加载数据到缓存中而且作到负载均衡。
 

实际上，对于应用系统中的每一台服务器，还须要一层防御机制，限流熔断，这样作的目的是为了防止单台机器请求量太高，使得服务器负载太高，不至于服务器宕机或者大量请求访问数据库。
 

简单思路就是为每一台服务器设计一个阀值，当请求量大于该值就直接返回用户空白页面或者提示用户几秒后刷新从新访问。
 

数据一致性
 

数据一致性问题主要体如今缓存更新的时候，如何更新缓存，保证数据库与缓存以及各层缓存层之间的一致性。
 

对于缓存更新问题，先写缓存仍是先写数据库，这里省略若干字。以前的文章介绍过，有兴趣的读者能够翻阅。
 

在单层缓存系统中，咱们能够先采用删除缓存而后更新数据库的方案来解决其数据一致性问题，那么对于多级缓存呢？
 

若是使用这种方案，咱们须要考虑，若是先删除缓存，那么须要逐层去作删除操做，那么这一系列操做对系统带来的耗时也是很可观的。
 

若是咱们使用分布式事务机制，就须要考虑该不应将写缓存放入事务当中，由于咱们更新分布式缓存，须要走网络通讯，大量的请求将致使网路抖动甚至阻塞，增长了系统的延迟，致使系统短期内不可用。
 

若是咱们不将写缓存这一操做放入事务当中，那么可能引发短期内数据不一致。
 

这也就是分布式系统的 CAP 理论，咱们不能同时达到高可用和一致性。那么该如何抉择呢？
 

这里咱们选择保证系统的可用性，就一个秒杀系统来说，短暂的不一致性问题对用户的体验影响并不大（固然，这里不涉及支付系统）。
 

而可用性对用户来讲却很重要，一个活动可能在很短的时间内结束，而用户须要在这段时间内抢到本身心仪的商品，因此可用性更重要一些（这里须要根据具体场景进行权衡）。
 

在保证了系统的可用性的基础上，咱们该如何实现呢？若是实时性要求不是很高，咱们能够采用全量+增量同步的方式进行。
 

首先，咱们能够按照预计的热点 Key 对系统进行缓存预热，全量同步数据到缓存系统。
 

接着，在须要更新缓存的时候，咱们能够采用增量同步的方式更新缓存。好比咱们可使用阿里 Canal 框架同步 Binlog 的方式进行数据的同步。
 

缓存过时
 

缓存系统中的全部数据，根据数据的使用频率以及场景，咱们能够分为过时 Key 以及不过时 Key，那么对于过时缓存咱们该如何淘汰呢？
 

下面有经常使用的几种方案：
FIFO：使用 FIFO 算法来淘汰过时缓存。
LFU：使用 LFU 算法来淘汰过时缓存。
LRU：使用 LRU 算法来淘汰过时缓存。
 

以上几种方案是在缓存达到最大缓存大小的时候的淘汰策略，若是没有达到最大缓存大小，咱们有下面几种方式：定时删除策略：设置一个定时任务，在规定时间内检查而且删除过时 Key。按期删除策略：这种策略须要设置删除的周期以及时长，如何设置，须要根据具体场合来计算。惰性删除策略：在使用时检查是否过时，若是过时直接去更新缓存，不然直接返回。