亿级请求下多级缓存那些事，你全部吃下了吗？

小鱼儿 2021-10-13 00:29 108阅读 0赞

# **什么是多级缓存** #

所谓多级缓存，即在整个系统架构的不同系统层级进行数据缓存，以提升访问效率，这也是应用最广的方案之一。我们应用的整体架构如图1所示：

![13894260-466874bd2ba25738][]

图1 多级缓存方案

**文末有福利赠送，如果你感兴趣的话可以去领取架构资料。**

**整体流程如上图所示：**

1）首先接入Nginx将请求负载均衡到应用Nginx，此处常用的负载均衡算法是轮询或者一致性哈希，轮询可以使服务器的请求更加均衡，而一致性哈希可以提升应用Nginx的缓存命中率，相对于轮询，一致性哈希会存在单机热点问题，一种解决办法是热点直接推送到接入层Nginx，一种办法是设置一个阀值，当超过阀值，改为轮询算法。

2）接着应用Nginx读取本地缓存（本地缓存可以使用Lua Shared Dict、Nginx Proxy Cache（磁盘/内存）、Local Redis实现），如果本地缓存命中则直接返回，使用应用Nginx本地缓存可以提升整体的吞吐量，降低后端的压力，尤其应对热点问题非常有效。

3）如果Nginx本地缓存没命中，则会读取相应的分布式缓存（如Redis缓存，另外可以考虑使用主从架构来提升性能和吞吐量），如果分布式缓存命中则直接返回相应数据（并回写到Nginx本地缓存）。

4）如果分布式缓存也没有命中，则会回源到Tomcat集群，在回源到Tomcat集群时也可以使用轮询和一致性哈希作为负载均衡算法。

5）在Tomcat应用中，首先读取本地堆缓存，如果有则直接返回（并会写到主Redis集群），为什么要加一层本地堆缓存将在缓存崩溃与快速修复部分细聊。

6）作为可选部分，如果步骤4没有命中可以再尝试一次读主Redis集群操作。目的是防止当从有问题时的流量冲击。

7）如果所有缓存都没有命中只能查询DB或相关服务获取相关数据并返回。

8）步骤7返回的数据异步写到主Redis集群，此处可能多个Tomcat实例同时写主Redis集群，可能造成数据错乱，如何解决该问题将在更新缓存与原子性部分细聊。

应用整体分了三部分缓存：应用Nginx本地缓存、分布式缓存、Tomcat堆缓存，每一层缓存都用来解决相关的问题，如应用Nginx本地缓存用来解决热点缓存问题，分布式缓存用来减少访问回源率、Tomcat堆缓存用于防止相关缓存失效/崩溃之后的冲击。

虽然就是加缓存，但是怎么加，怎么用细想下来还是有很多问题需要权衡和考量的，接下来部分我们就详细来讨论一些缓存相关的问题。

# **如何缓存数据** #

接下来部将从缓存过期、维度化缓存、增量缓存、大Value缓存、热点缓存几个方面来详细介绍如何缓存数据。

# **过期与不过期** #

对于缓存的数据我们可以考虑不过期缓存和带过期时间缓存，什么场景应该选择哪种模式需要根据业务和数据量等因素来决定。

**不过期缓存**场景一般思路如图2所示：

![13894260-c29c279e6309e2fc][]

亿级请求下多级缓存那些事，你全部吃下了吗？

图2不过期缓存方案

使用Cache-Aside模式，首先写数据库，如果成功，则写缓存。这种场景下存在事务成功、缓存写失败但无法回滚事务的情况。另外，不要把写缓存放在事务中，尤其写分布式缓存，因为网络抖动可能导致写缓存响应时间很慢，引起数据库事务阻塞。如果对缓存数据一致性要求不是那么高，数据量也不是很大，则可以考虑定期全量同步缓存。

也有提到如下思路：先删缓存，然后执行数据库事务；不过这种操作对于如商品这种查询非常频繁的业务不适用，因为在你删缓存的同时，已经有另一个系统来读缓存了，此时事务还没有提交。当然对于如用户维度的业务是可以考虑的。

不过为了更好地解决以上多个事务的问题，可以考虑使用订阅数据库日志的架构，如使用canal订阅mysql的binlog实现缓存同步。

对于长尾访问的数据、大多数数据访问频率都很高的场景、缓存空间足够都可以考虑不过期缓存，比如用户、分类、商品、价格、订单等，当缓存满了可以考虑LRU机制驱逐老的缓存数据。

**1. 过期缓存机制**

即采用懒加载，一般用于缓存别的系统的数据（无法订阅变更消息、或者成本很高）、缓存空间有限、低频热点缓存等场景；常见步骤是：首先读取缓存如果不命中则查询数据，然后异步写入缓存并过期缓存，设置过期时间，下次读取将命中缓存。热点数据经常使用即在应用系统上缓存比较短的时间。这种缓存可能存在一段时间的数据不一致情况，需要根据场景来决定如何设置过期时间。如库存数据可以在前端应用上缓存几秒钟，短时间的不一致时可以忍受的。

**2. 维度化缓存与增量缓存**

对于电商系统，一个商品可能拆成如基础属性、图片列表、上下架、规格参数、商品介绍等；如果商品变更了要把这些数据都更新一遍那么整个更新成本很高：接口调用量和带宽；因此最好将数据进行维度化并增量更新（只更新变的部分）。尤其如上下架这种只是一个状态变更，但是每天频繁调用的，维度化后能减少服务很大的压力。

![13894260-d54f970cb55b2a08][]

亿级请求下多级缓存那些事，你全部吃下了吗？

图3 维度化缓存方案

按照不同维度接收MQ进行更新。

**3. 大Value 缓存**

要警惕缓存中的大Value，尤其是使用Redis时。遇到这种情况时可以考虑使用多线程实现的缓存，如Memcached，来缓存大Value；或者对Value进行压缩；或者将Value拆分为多个小Value，客户端再进行查询、聚合。

**4. 热点缓存**

对于那些访问非常频繁的热点缓存，如果每次都去远程缓存系统中获取，可能会因为访问量太大导致远程缓存系统请求过多、负载过高或者带宽过高等问题，最终可能导致缓存响应慢，使客户端请求超时。一种解决方案是通过挂更多的从缓存，客户端通过负载均衡机制读取从缓存系统数据。不过也可以在客户端所在的应用/ 代理层本地存储一份，从而避免访问远程缓存，即使像库存这种数据，在有些应用系统中也可以进行几秒钟的本地缓存，从而降低远程系统的压力。

# **架构视频学习** #

分享一些架构学习的视频资料，想要的可以自己去领取。

![13894260-e6caa858fae96e5f][]

亿级请求下多级缓存那些事，你全部吃下了吗？

**当然还有更多，这边就不一一列举了，你如果觉得你能全部吃下，也不挡着你要到更多。**

**视频获取方式：【点击链接免费领取】[https://shimo.im/docs/QzafqtfKU4MoODI9/read][https_shimo.im_docs_QzafqtfKU4MoODI9_read]**

# **最后的话** #

**为什么某些人会一直比你优秀，是因为他本身就很优秀还一直在持续努力变得更优秀。而你是不是还在满足于现状且内心在窃喜?“对于程序员来说，如果哪一天开始他停止了学习，那么他的职业生涯便开始宣告消亡。”所以行动起来，学习起来！**

[13894260-466874bd2ba25738]: /images/20211013/e67cc308d07e4fa6bc871aedafe171cf.png
[13894260-c29c279e6309e2fc]: /images/20211013/67fbd223eda64fc6a88c5927615e9c38.png
[13894260-d54f970cb55b2a08]: /images/20211013/0e11e85baa0d47faa9fc9b3b81f1e8a6.png
[13894260-e6caa858fae96e5f]: /images/20211013/a008d836110b4c84aba7acb92e0c2c6a.png
[https_shimo.im_docs_QzafqtfKU4MoODI9_read]: https://links.jianshu.com/go?to=https%3A%2F%2Fshimo.im%2Fdocs%2FQzafqtfKU4MoODI9%2Fread