.NET 6開發之實現緩存過程詳解

Posted on by

需求

有的時候為瞭減少客戶端請求相同資源的邏輯重復執行，我們會考慮使用一些緩存的方式，在.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返回：

一點擴展

但是如果我們仔細觀察和思考就會發現，框架在實現緩存校驗上存在兩個問題：

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

這兩個問題是由框架內建的ResponseCaching庫導致的，可以認為它沒有正確地實現緩存校驗機制。為此我們有一些替代方案可供參考：

Varnish

Apache Traffic Server

Squid

當然使用專門的CDN來做緩存也是可以的。

總結

在本文中我們主要演示瞭如何借助框架的緩存機制來實現請求資源的緩存，盡管在緩存校驗的實現上，官方提供的庫目前來看並沒有能很好地完成功能以外，對於我們基本的使用場景來說已經夠用瞭。下一篇文章我們來看怎麼實現接口的限流。

參考資料

1.Varnish

2.Apache Traffic Server

3.Squid

到此這篇關於.NET 6開發之實現緩存過程詳解的文章就介紹到這瞭,更多相關.NET 6實現緩存內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：