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

流程如下：

当接收到一个请求时，首先会分发到nginx集群中，这里可以采用nginx的负载均衡算法分发给某一台机器，使用轮询可以降低负载，或者采用一致性hash算法来提升缓存命中率。

当nginx层没有缓存数据时，会继续向下请求，在分布式缓存集群中查找数据，如果缓存命中，直接返回(并且写入nginx应用缓存中)，如果未命中，则回源到tomcat集群中查询堆内缓存。

在分布式缓存中查询不到数据，将会去tomcat集群中查询堆内缓存，查询成功直接返回(并写入分redis主集群中)，查询失败请求数据库;堆内缓存。

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

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

缓存热点

缓存热点，是一个很常见的问题，比如“某某明星宣布结婚”等等，都可能产生大量请求访问的问题，一个最麻烦也是最容易让人忽视的事情就是如何探测到热点key，在缓存系统中，除了一些常用的热点key外，在某些特殊场合下也会出现大量的热点key，我们该如何发现呢?有以下策略：

数据调研。可以分析历史数据以及针对不同的场合去预测出热点key，这种方式虽然不能百分百使得缓存命中，但是却是一种最简单和节省成本的方案。

实时计算。可以使用现有的实时计算框架，比如storm、spark streaming、flink等框架统计一个时间段内的请求量，从而判断热点key。或者也可以自己实现定时任务去统计请求量。

这里我们着重讨论一下第二种解决方案，对于热点key问题，当缓存系统中没有发现缓存时，需要去数据库中读取数据，当大量请求来的时候，一个请求获取锁去请求数据库，其他阻塞，接着全部去访问缓存，这样可能因为一台服务器撑不住从而宕机，比如正常一台服务器并发量为5w左右，产生热点key的时候达到了10w甚至20w，这样服务器肯定会崩。所以我们在发现热点key之后还需要做到如何自动负载均衡。并且做到负载均衡。

实际上，对于应用系统中的每一台服务器，还需要一层防护机制，限流熔断，这样做的目的是为了防止单台机器请求量过高，使得服务器负载过高，不至于服务器宕机或者大量请求访问数据库。简单思路就是为每一台服务器设计一个阀值，当请求量大于该值就直接返回用户空白页面或者提示用户几秒后刷新重新访问。

数据一致性

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

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

在单层缓存系统中，我们可以先删除缓存然后更新数据库的方案来解决其数据一致性问题，那么对于多级缓存呢?如果使用这种方案，我们需要考虑，如果先删除缓存，那么需要逐层去做删除操作，那么这一系列操作对系统带来的耗时也是和可观的。

如果我们使用分布式事务机制，就需要考虑该不该将写缓存放入事务当中，因为我们更新分布式缓存，需要走网络通信，大量的请求将导致网路抖动甚至阻塞，增加了系统的延迟，导致系统短时间内不可用。如果我们不将写缓存这一操作放入事务当中，那么可能引起短时间内数据不一致。这也就是分布式系统的CAP理论，我们不能同时达到高可用和一致性。那么该如何抉择呢?

这里我们选择保证系统的可用性，就一个秒杀系统来讲，短暂的不一致性问题对用户的体验影响并不大(当然，这里不涉及支付系统)，而可用性对用户来说却很重要，一个活动可能在很短的时间内结束，而用户需要在这段时间内抢到自己

（编辑：通化站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!