需求

有的時(shí)候?yàn)榱藴p少客戶端請(qǐng)求相同資源的邏輯重復(fù)執(zhí)行，我們會(huì)考慮使用一些緩存的方式，在.NET 6中，我們可以借助框架提供的中間件來實(shí)現(xiàn)請(qǐng)求資源的緩存。

目標(biāo)

實(shí)現(xiàn)請(qǐng)求結(jié)果的緩存。

原理與思路

對(duì)于在.NET6中實(shí)現(xiàn)緩存，我們可以使用響應(yīng)緩存中間件ResponseCaching來實(shí)現(xiàn)，同時(shí)可以使用Marvin.Cache.Headers來為我們提供更多的緩存相關(guān)的屬性。

實(shí)現(xiàn)

使用原生ResponseCaching實(shí)現(xiàn)緩存

既然是中間件，我們便在Program中引入：

Program.cs

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

在使用方法上，有幾種方式可以實(shí)現(xiàn)配置：1)進(jìn)行全局的配置，應(yīng)用于所有添加了相同ProfileName的ResponseCache的Controller響應(yīng)；2)對(duì)單個(gè)Controller/Action進(jìn)行配置，應(yīng)用于當(dāng)前作用的Controller/Action；3)全局配置后，由單個(gè)Controller/Action覆蓋全局配置。我們會(huì)演示1)和3)的場(chǎng)景。

我們準(zhǔn)備使用獲取所有TodoLists的接口進(jìn)行演示。

先看如何進(jìn)行全局配置：

Program.cs

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

驗(yàn)證1: 全局配置Caching

首先給我們要進(jìn)行驗(yàn)證的Action添加屬性：

TodoListController.cs

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

啟動(dòng)Api項(xiàng)目，第一次執(zhí)行獲取TodoLists的請(qǐng)求：

請(qǐng)求

響應(yīng)

響應(yīng)頭中多了一個(gè)cache-control字段用于指明緩存的類型（public）以及過期時(shí)間為60s：

如果你是使用Postman或者Insomia發(fā)送的請(qǐng)求，那么在過期前再次發(fā)起相同請(qǐng)求的返回頭中會(huì)再多出一個(gè)Age字段，用于表明該資源當(dāng)前緩存了多少秒（Hoppscotch我沒找到可以在哪里設(shè)置，所以下面的截圖是來自Insomia，如果有哪位老哥知道的可以教一下）：

同時(shí)如果觀察日志的話會(huì)發(fā)現(xiàn)，第二次請(qǐng)求并沒有實(shí)際執(zhí)行SQL語句，這也證明了第二次請(qǐng)求的返回來自緩存：

如果間隔60s以上我們?cè)偃グl(fā)送相同的請(qǐng)求，會(huì)發(fā)現(xiàn)日志中是這樣的：

可以看到緩存已經(jīng)失效了，此時(shí)需要重新向數(shù)據(jù)庫查詢返回?cái)?shù)據(jù)，并將這次請(qǐng)求結(jié)果緩存起來。

驗(yàn)證2: 單個(gè)Action覆蓋全局配置

我們還是使用這個(gè)接口，但是修改一下屬性：

TodoListController.cs

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

重新啟動(dòng)Api項(xiàng)目，第一次執(zhí)行獲取TodoLists的請(qǐng)求，請(qǐng)求和驗(yàn)證1相同，我們來看響應(yīng)中的變化：

響應(yīng)

可以看到失效時(shí)間已經(jīng)變?yōu)?20s了，其他不再一一驗(yàn)證。

使用Marvin.Cache.Headers實(shí)現(xiàn)更多緩存功能

在緩存中還有一個(gè)問題是，如果判斷緩存的數(shù)據(jù)內(nèi)容已經(jīng)變化，就需要去獲取最新的響應(yīng)而不是直接從緩存中取值。這是借助緩存校驗(yàn)來完成的，而常使用的方式是通過Etag實(shí)現(xiàn)。示意的過程如下：

如果首次請(qǐng)求資源，API會(huì)在響應(yīng)頭中添加Etag和Last-Modified字段：

當(dāng)客戶端再次請(qǐng)求資源時(shí)，由于緩存自身是不知道資源有沒有被修改，所以緩存會(huì)攜帶If-None-Match字段（和客戶端收到的Etag值相等）和If-Modified-Since字段（和客戶端收到的Last-Modified值相等）到API端，如果校驗(yàn)發(fā)現(xiàn)資源沒有發(fā)生修改，那么API端無需重新獲取資源，直接返回304字段（NotModifed）給緩存，緩存給客戶端返回值。如果校驗(yàn)發(fā)現(xiàn)資源發(fā)生了修改，那么API將會(huì)返回新的結(jié)果。

我們給Api項(xiàng)目添加Nuget包Marvin.Cache.Headers，來實(shí)現(xiàn)此功能。

首先向Program中添加服務(wù)以及引入中間件：

Program.cs

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

同時(shí)我們需要移除之前添加的ResponseCache屬性，因?yàn)樾乱氲膸煲呀?jīng)幫我們完成了，當(dāng)然我們也可以通過以下方式覆蓋全局配置：

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

覆蓋規(guī)則和框架內(nèi)置的規(guī)則是一致的，我不會(huì)繼續(xù)演示。

驗(yàn)證3: 緩存校驗(yàn)

請(qǐng)求仍然是獲取所有的TodoLists：

響應(yīng)

我們暫時(shí)只關(guān)注響應(yīng)頭：

如果在緩存失效前我們添加了一個(gè)新的TodoList，在請(qǐng)求頭中添加If-None-Match=53154EEFAE230D733827DBDE49B42AF9再執(zhí)行獲取請(qǐng)求：

可以看到在失效時(shí)間到期之內(nèi)，Etag值已經(jīng)發(fā)生了變化，校驗(yàn)表明資源已經(jīng)改變，需要重新獲取。

如果我們?cè)俅潍@取相同的資源，會(huì)得到304返回：

一點(diǎn)擴(kuò)展

但是如果我們仔細(xì)觀察和思考就會(huì)發(fā)現(xiàn)，框架在實(shí)現(xiàn)緩存校驗(yàn)上存在兩個(gè)問題：

1. If-None-Match頭字段是我們手動(dòng)添加模擬的，這本應(yīng)該由緩存中間件來完成；
2. 在響應(yīng)304的情況下，實(shí)際上是沒有返回響應(yīng)體的，即緩存中未修改的資源沒有返回；

這兩個(gè)問題是由框架內(nèi)建的ResponseCaching庫導(dǎo)致的，可以認(rèn)為它沒有正確地實(shí)現(xiàn)緩存校驗(yàn)機(jī)制。為此我們有一些替代方案可供參考：

Varnish

Apache Traffic Server

Squid

當(dāng)然使用專門的CDN來做緩存也是可以的。

總結(jié)

在本文中我們主要演示了如何借助框架的緩存機(jī)制來實(shí)現(xiàn)請(qǐng)求資源的緩存，盡管在緩存校驗(yàn)的實(shí)現(xiàn)上，官方提供的庫目前來看并沒有能很好地完成功能以外，對(duì)于我們基本的使用場(chǎng)景來說已經(jīng)夠用了。下一篇文章我們來看怎么實(shí)現(xiàn)接口的限流。

參考資料

1.Varnish

2.Apache Traffic Server

3.Squid

到此這篇關(guān)于.NET 6開發(fā)之實(shí)現(xiàn)緩存過程詳解的文章就介紹到這了,更多相關(guān).NET 6實(shí)現(xiàn)緩存內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論