1. 浏览器缓存

1.1 简述

通过控制响应头信息，告诉浏览器让其将对应的数据缓存到本地，在指定时间范围内，可直接从本地缓存中取即可，但浏览器方可以不选择走缓存。

1.2 案例演示

本文中还是使用WebAPI项目进行演示，只是通过不同的API来区分不同案例。

创建好项目中，在默认的WeatherForecastController中添加一个Action方法，如下：

这个时候还没有做缓存处理，所以只要访问都会调用接口获取最新的数据。

在接口方法上只需添加ResponseCache特性就可以实现浏览器缓存，如下：

这样就可以实现客户端缓存了，可能会有小伙伴会点击浏览器的刷新和F5进行测试，这个时候并没有看到缓存效果，其实这个时候浏览器是以新的请求发出的，并不会去缓存里取，但其实请求获取到的数据已经存缓存了。

那怎么去测试呢？每次都打开多个浏览器标签或用Swagger的形式，如下：

第一次访问：

每次都打开新标签，再访问接口：

除了根据数据没变来判定是缓存数据外，还可以通过请求确定是否从本地缓存中取数据，如下：

Swagger演示，关于如何集成Swagger，之前有专门分享过(跟我一起学.NetCore之Swagger让前后端不再烦恼及界面自定义)：

浏览器缓存的原理其实就是在响应头中增加Cache-Control(ResponseCache的方式是通过Action过滤器的形式设置的响应头)，告诉浏览器进行数据缓存，在指定时间范围内可以从缓存中取，我们也可以自己手动设置响应头信息来达到同样的效果，如下：

尽管数据已经缓存，浏览器也可以选择不从缓存取，如下：

2. 服务器缓存

2.1 简述

浏览器缓存只是将数据保存在单台电脑的不同位置，如果打开不同的浏览器或不同的电脑访问时，还是起不到缓存的效果，所以搞个服务器缓存肯定是个不错的选择。

即将数据缓存到站点服务器中，当请求过来时，如果命中缓存，直接获取返回即可，不调用对应的后台API。

2.2 案例

其实这只是在原来浏览器缓存的基础上增加了一个中间件的处理，如下：

代码如下：

运行效果：

由于不同的浏览器保存的数据位置不一样，如果仅仅是本地缓存，那么两个浏览器的数据会返回不一样；另外第一个浏览器访问之后，其他浏览器在时间范围内获得结果是一样的，也不会调用后台接口。

这种服务器端的缓存在有些情况是不生效的，如：请求Method不是Get或Head的不缓存，返回状态码不是200的不缓存，请求头包含Authorization的不缓存等，所以基本很少用这种方式进行缓存操作。

3. 应用内存缓存

3.1 简述

对于上面说到的浏览器缓存和服务器缓存，如果是友好的用户访问，没问题，能起到一定的效果；但如果有人要使坏，不设置对应的请求头访问API(禁用缓存)，最终还是会给应用服务器和数据库服务器带来压力。所以需要一种能主动控制的缓存方式，后端程序就是下手的对象，在后端程序中写缓存逻辑，这样缓存策略就由我们自己控制了。

虽然每次请求都会进入应用程序，但会先从缓存中进行获取数据，如果命中缓存，就不再进行数据库访问，直接将缓存数据返回。