【Java知识点详解 8】缓存

关注

转载最新推荐文章于 2026-04-24 11:27:40 发布 3.2w 阅读 AI 写同款· GEO 优化 ›

多级缓存之JVM进程缓存传统的缓存策略一般是请求到达Tomcat后，先查询Redis，如果未命中则查询数据库，在多级缓存架构中，Nginx内部需要编写本地缓存查询、Redis查询、Tomcat查询的业务逻辑，因此这样的nginx服务不再是一个反向代理服务器，而是一个编写业务的Web服务器了。缓存在日常开发中启动至关重要的作用，由于是存储在内存中，数据的读取速度是非常快的，能大量减少对数据库的访问，减少数据库的压力。Caffeine是一个基于Java8开发的，提供了近乎最佳命中率的高性能的本地缓存库。阅读详情

🍅 Java学习路线推荐：Java基础教程系列

🍅 SpringBoot精品推荐：Spring Boot基础教程

🍅 简介：Java领域优质创作者🏆、优快云哪吒公众号作者✌ 、Java架构师奋斗者💪

🍅 扫描主页左侧二维码，加入群聊，一起学习、一起进步

🍅 欢迎点赞 👍 收藏 ⭐留言 📝

一、前言

缓存可以让原本打开很慢的页面，变得能“秒开”。平时访问的APP与网站几乎都涉及缓存的运用。

那么，缓存除了能加速数据的访问之外，还有什么作用呢？

另外，任何事物都有两面性，我们如何才能将缓存的优点发挥的淋漓尽致，同时避免它的弊端呢？

本文就给大家分享一下如何理解缓存，以及它的运用思路，希望对大家有所启发。

二、缓存能做什么？

正如前面所说，大家最普遍的理解就是当我们遇到某个页面打开很慢的时候，会想到引入缓存，这样页面打开就快了。其实快和慢是相对的，从技术角度来说，缓存之所以快是因为缓存是基于内存去建立的，而内存的读写速度比硬盘快很多倍，所以用内存来代替磁盘作为读写的介质自然能大大提高访问数据的速度。

这个过程大致是这样的，通过在内存中存储被访问过的数据供后续访问时使用，以此来达到提速的效果。

其实除此之外，缓存还有另外两个重要的运用方式：预读取和延迟写。

三、预读取

预读取就是预先读取将要载入的数据，也可以称作“预存预热”，它是在系统中先将硬盘中的一部分加载到内存中，然后再对外提供服务。

为什么要这么做呢？因为有些系统一旦启动就要面临数以万计的请求进来，如果直接让这些请求打到数据库上，非常大的可能是数据库压力暴增，直接被反扒下，无法正常响应。

为了缓解这个问题，就需要通过“预读取”来解决。

可能你会玩，哪怕用了缓存还是扛不住吗？那就是做横向扩展和负载均衡的时候了，这不是本文讨论的内容，有机会再专门分享吧。

如果说“预读取”是在“数据出口”加了一道前置的缓冲区的话，那么下面要说的“延迟写”就是在“数据入口”后面加了一道后置的缓冲区。

四、延迟写

你可能知道，数据库的写入速度是慢于读取速度的，因为写入的时候有一系列的保证数据准确性的机制。所以，如果想提升写入速度的话，要么做分库分表，要么就是通过缓存来进行一道缓冲，再一次性批量写到磁盘，以此来提速。

由于分库分表对跨表操作以及多条件组合查询的副作用巨大，所以引入它的复杂度大于引入缓存，我们应当优先考虑引入缓存的方案。

那么，通过缓存机制来加速“写”的过程就可以称作“延迟写”，它是预先将需要写入磁盘或数据库的数据，暂时写入到内存，然后返回成功，再定时将内存中的数据批量写入到磁盘。

可能你会想，写到内存就认为成功，万一中途出现意外、断电、停机等导致程序异常终止的情况，数据不就丢失了吗？

是的，所以“延迟写”一般仅用于对数据完整性要求不是那么苛刻的场景，比如点赞数、参与用户数等等，可以大大缓解对数据库频繁修改所带来的压力。

其实在我们熟知的分布式缓存Redis中，其默认运用的持久化机制---RDB，也是这样的思路。

在一个成熟的系统中，能够运用到缓存的地方其实并不是一处。下面就来梳理一下我们在那些地方可以加“缓存”。

五、哪里可以加缓存？

在说哪里可以加缓存之前我们先搞清楚一个事情，我们要缓存什么？也就是符合什么特点的数据才需要加缓存？毕竟加缓存是一个额外的成本投入，得物有所值。

一般来说你可以用两个标准来衡量：

热点数据：被高频访问，如几十次/秒以上。

静态数据：很少变化，读大于写。

接下来就可以替他们找到合适的地方加缓存了。

缓存的本质是一个“防御性”的机制，而系统之间的数据流转是一个有序的过程，所以，选择在哪里加缓存就相当于选择在一条马路的哪个位置设路障。在这个路障之后的道路都能受到保护，不被车流碾压。

那么在以终端用户为起点，系统所用的数据库为终点的这条道路上可以作为缓存设立点的位置大致有以下这些：

每个设立点可以挡掉一些流量，最终形成一个漏斗状的拦截效果，以此保护最后面的系统以及最终的数据库。

下面简要描述一下每个运用场景以及需要注意的点。

六、缓存类别

1、浏览器缓存

这是离用户最近的可以作为缓存的地方，而且借助的是用户的“资源”（缓存的数据在用户的终端设备上），性价比可谓最好，让用户帮你分担压力。

当你打开浏览器的开发者工具，看到 from cache 或者 from memory cache、from disk cache 的时候，就意味着这些数据已经被缓存在了用户的终端设备上了，没网的时候也能访问到一部分内容就是这个原因。

这个过程是浏览器替我们完成的，一般用于缓存图片、js 与 css 这些资源，我们可以通过 Http 消息头中的 Cache-Control 来控制它，具体细节这里就不展开了。此外，js 里的全局变量、cookie 等运用也属于该范畴。

浏览器缓存是在用户侧的缓存点，所以我们对它的掌控力比较差，在没有发起新请求的情况下，你无法主动去更新数据。

2、CDN缓存

提供CDN服务的服务商，在全国甚至是全球部署着大量的服务器节点（可以叫做“边缘服务器”）。那么将数据分发到这些遍布各地服务器上作为缓存，让用户访问就近的服务器上的缓存数据，就可以起到压力分摊和加速效果。这在TOC类型的系统上运用，效果格外显著。

但是需要注意的是，由于节点众多，更新缓存数据比较缓慢，一般至少是分钟级别，所以一般仅适用于不经常变动的静态数据。

解决方式也是有的，就是在 url 后面带个自增数或者唯一标示，如 ?v=1001。因为不同的 url 会被视作“新”的数据和文件，被重新 create 出来。

3、网关（代理）缓存

很多时候我们在源站前面加一层网关，为的是做一些安全机制或者作为统一分流策略的入口。

同时这里也是做缓存的一个好场所，毕竟网关是“业务无关”的，它能够拦下来请求，对背后的源站也有很大的受益，减少了大量的CPU运算。

常用的网关缓存有Varnish、Squid与Ngnix。一般情况下，简单的缓存运用场景，用Ngnix即可，因为大部分时候我们会用它做负载均衡，能少引入一个技术就少一分复杂度。如果是大量的小文件可以使用Varnish，而 Squid 则相对大而全，运用成本也更高一些。

4、进程内缓存

可能我们大多数程序员第一次刻意使用缓存的场景就是这个时候。

一个请求能走到这里说明它是“业务相关”的，需要经过业务逻辑的运算。

也正因如此，从这里开始对缓存的引入成本比前面3种大大增加，因为对缓存与数据库之间的“数据一致性”要求更高了。

5、进程外缓存

这个大家也熟悉，就是 Redis 与 Memcached 之类，甚至也可以自己单独写一个程序来专门存放缓存数据，供其它程序远程调用。

这里先多说几句关于 Redis 和 Memcached 该怎么选择的思路。

对资源（CPU、内存等）利用率格外重视的话可以使用Memcached ，但程序在使用的时候需要容忍可能发生的数据丢失，因为纯内存的机制。如果无法容忍这单，并对资源利用率也比较豪放的话就可以使用Redis。而且Redis的数据库结构更多， Memcached 只有 key-value，更像是一个 NoSQL 存储。