使用.NET 6開發TodoList應用(22)——實作快取-有解無憂

系列導航及源代碼

使用.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回傳：