千万级并发！如何设计一个多级缓存系统？ _多级缓存系统

文章插图

首先我们需要明白，什么是一个多级缓存系统，它有什么用。所谓多级缓存系统，就是指在一个系统的不同的架构层级进行数据缓存，以提升访问效率。
我们都知道，一个缓存系统，它面临着许多问题，比如缓存击穿，缓存穿透，缓存雪崩，缓存热点等等问题，那么，对于一个多级缓存系统，它有什么问题呢？
缓存热点：多级缓存系统大多应用在高并发场景下，所以我们需要解决热点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数据，去数据库中加载数据到缓存中并且做到负载均衡。