缓存架构之多级缓存（一）多级缓存及每一层的意义

我们之前在缓存架构之redis中，主要讲解的是redis是如何支持高并发的，它的内部原理的基本思路等。在一个高并发的系统中，redis就是底层的缓存存储的支持，可以说是重中之重。 但是不要以为，做个缓存，就是用一下redis就够了，简单的缓存系统，那么做自然ok，但是在复杂的高并发情况的，遇到的问题非常多，绝不是简单的访问一下redsi就可以了。

多级缓存介绍

nginx本地缓存+redis分布式缓存+tomcat堆缓存的多级缓存

nginx本地缓存，抗的是热数据的高并发访问。我们以电商为例，一般来讲，商品的购买总是有热点的，比如访问某些知名品牌的次数会比小众品牌次数多。这些热数据，由于经常被访问，我们可以利用nginx本地缓存。由于nginx本地内存有限，我们只cache住部分热数据，其余不怎么热的数据，流量可以走redis。

redis大规模分布式缓存集群，抗的是很高的离散访问,支撑海量的数据，高并发的访问，提供高可用的服务。

tomcat 的jvm堆内存缓存，主要是抗redis大规模灾难（比如雪崩），如果redis出现了大规模的宕机，导致nginx大量流量直接涌入数据生产服务，那么最后的tomcat堆内存缓存至少可以再抗一下，不至于让数据库直接裸奔。同时tomcat jvm堆内存缓存，也可以抗住redis没有cache住的最后那少量的部分缓存。

例子

我们以常见的电商库存为例，一般来讲，显示的库存，是时效性要求相对较高一些（相比于商品基本信息，颜色、日期什么的）。我们希望当库存变化的时候，尽可能更快将库存显示到页面上去，而不是说等了很长时间，库存才反应到页面上去。

对于库存这种时效性要求高的数据，当相关的服务系统每次发生了变更的时候，直接采取数据库和redis缓存双写的方案，这样缓存的时效性最高。

商品基本信息等时效性不高的数据，而且种类繁多，来自多种不同的系统，采取MQ异步通知的方式，写一个数据生产服务，监听MQ消息，然后异步拉取服务的数据，更新tomcat jvm缓存+redis缓存

nginx+lua脚本做页面动态生成的工作，每次请求过来，优先从nginx本地缓存中提取各种数据，结合页面模板，生成需要的页面。

如果nginx本地缓存过期了，那么就从nginx到redis中去拉取数据，更新到nginx本地。

如果redis中也被LRU算法清理掉了，那么就从nginx走http接口到后端的服务中拉取数据，数据生产服务中，现在本地tomcat里的jvm堆缓存中找，ehcache，如果也被LRU清理掉了，那么就重新发送请求到源头的服务中去拉取数据，然后再次更新tomcat堆内存缓存+redis缓存，并返回数据给nginx，nginx缓存到本地。

三级缓存架构图.png