使用.NET 6开发TodoList应用(22)——实现缓存

2022 年 1 月 7 日
筆記
.NET 6, .NET基础系列, WebApi

系列导航及源代码

使用.NET 6开发TodoList应用文章索引

需求

有的时候为了减少客户端请求相同资源的逻辑重复执行，我们会考虑使用一些缓存的方式，在.NET 6中，我们可以借助框架提供的中间件来实现请求资源的缓存。

目标

实现请求结果的缓存。

原理与思路

对于在.NET6中实现缓存，我们可以使用响应缓存中间件ResponseCaching来实现，同时可以使用Marvin.Cache.Headers来为我们提供更多的缓存相关的属性。

实现

使用原生ResponseCaching实现缓存

既然是中间件，我们便在Program中引入：

Program.cs

// 省略其他...
// 配置缓存中间件
builder.Services.AddResponseCaching();
builder.Services.AddControllers();
// ...
// 使用缓存中间件
app.UseResponseCaching();
app.MapControllers();

在使用方法上，有几种方式可以实现配置：1)进行全局的配置，应用于所有添加了相同ProfileName的ResponseCache的Controller响应；2)对单个Controller/Action进行配置，应用于当前作用的Controller/Action；3)全局配置后，由单个Controller/Action覆盖全局配置。我们会演示1)和3)的场景。

我们准备使用获取所有TodoLists的接口进行演示。

先看如何进行全局配置：

Program.cs

// 省略其他...
builder.Services.AddControllers(options =>
{
    options.CacheProfiles.Add("60SecondDuration", new CacheProfile { Duration = 60 });
});

验证1: 全局配置Caching

首先给我们要进行验证的Action添加属性：

TodoListController.cs

// 省略其他...
[HttpGet]
[ResponseCache(CacheProfileName = "60SecondDuration")]
public async Task<ApiResponse<List<TodoListBriefDto>>> Get()
{
    return ApiResponse<List<TodoListBriefDto>>.Success(await _mediator.Send(new GetTodosQuery()));
}

启动Api项目，第一次执行获取TodoLists的请求：

请求
响应

响应头中多了一个cache-control字段用于指明缓存的类型（public）以及过期时间为60s：

如果你是使用Postman或者Insomia发送的请求，那么在过期前再次发起相同请求的返回头中会再多出一个Age字段，用于表明该资源当前缓存了多少秒（Hoppscotch我没找到可以在哪里设置，所以下面的截图是来自Insomia，如果有哪位老哥知道的可以教一下）：

同时如果观察日志的话会发现，第二次请求并没有实际执行SQL语句，这也证明了第二次请求的返回来自缓存：

如果间隔60s以上我们再去发送相同的请求，会发现日志中是这样的：

可以看到缓存已经失效了，此时需要重新向数据库查询返回数据，并将这次请求结果缓存起来。

验证2: 单个Action覆盖全局配置

我们还是使用这个接口，但是修改一下属性：

TodoListController.cs

[HttpGet]
[ResponseCache(Duration = 120)]
public async Task<ApiResponse<List<TodoListBriefDto>>> Get()
{
    return ApiResponse<List<TodoListBriefDto>>.Success(await _mediator.Send(new GetTodosQuery()));
}

重新启动Api项目，第一次执行获取TodoLists的请求，请求和验证1相同，我们来看响应中的变化：

响应

可以看到失效时间已经变为120s了，其他不再一一验证。

使用`Marvin.Cache.Headers`实现更多缓存功能

在缓存中还有一个问题是，如果判断缓存的数据内容已经变化，就需要去获取最新的响应而不是直接从缓存中取值。这是借助缓存校验来完成的，而常使用的方式是通过Etag实现。示意的过程如下：

如果首次请求资源，API会在响应头中添加Etag和Last-Modified字段：

当客户端再次请求资源时，由于缓存自身是不知道资源有没有被修改，所以缓存会携带If-None-Match字段（和客户端收到的Etag值相等）和If-Modified-Since字段（和客户端收到的Last-Modified值相等）到API端，如果校验发现资源没有发生修改，那么API端无需重新获取资源，直接返回304字段（NotModifed）给缓存，缓存给客户端返回值。如果校验发现资源发生了修改，那么API将会返回新的结果。

我们给Api项目添加Nuget包Marvin.Cache.Headers，来实现此功能。

首先向Program中添加服务以及引入中间件：

Program.cs

builder.Services.AddResponseCaching();
builder.Services.AddHttpCacheHeaders(
    expirationOptions =>
    {
        expirationOptions.MaxAge = 180;
        expirationOptions.CacheLocation = CacheLocation.Private;
    },
    validateOptions =>
    {
        validateOptions.MustRevalidate = true;
    });
// 省略其他...
app.UseResponseCaching();
app.UseHttpCacheHeaders();

同时我们需要移除之前添加的ResponseCache属性，因为新引入的库已经帮我们完成了，当然我们也可以通过以下方式覆盖全局配置：

[HttpCacheExpiration(CacheLocation = CacheLocation.Public, MaxAge = 60)]
[HttpCacheValidation(MustRevalidate = false)]

覆盖规则和框架内置的规则是一致的，我不会继续演示。

验证3: 缓存校验

请求仍然是获取所有的TodoLists：

响应
我们暂时只关注响应头：

如果在缓存失效前我们添加了一个新的TodoList，在请求头中添加If-None-Match=53154EEFAE230D733827DBDE49B42AF9再执行获取请求：

可以看到在失效时间到期之内，Etag值已经发生了变化，校验表明资源已经改变，需要重新获取。
如果我们再次获取相同的资源，会得到304返回：

一点扩展

但是如果我们仔细观察和思考就会发现，框架在实现缓存校验上存在两个问题：

If-None-Match头字段是我们手动添加模拟的，这本应该由缓存中间件来完成；
在响应304的情况下，实际上是没有返回响应体的，即缓存中未修改的资源没有返回；

这两个问题是由框架内建的ResponseCaching库导致的，可以认为它没有正确地实现缓存校验机制。为此我们有一些替代方案可供参考：

• Varnish
• Apache Traffic Server
• Squid

当然使用专门的CDN来做缓存也是可以的。

总结

在本文中我们主要演示了如何借助框架的缓存机制来实现请求资源的缓存，尽管在缓存校验的实现上，官方提供的库目前来看并没有能很好地完成功能以外，对于我们基本的使用场景来说已经够用了。下一篇文章我们来看怎么实现接口的限流。

参考资料

Tags: .NET 6 .NET基础系列 WebApi