ASP.NET Core 中的快取概觀

作者：Rick Anderson 與 Ryan Nowak

記憶體內部快取

記憶體內部快取會使用伺服器記憶體來儲存快取的資料。 這種類型的快取適合使用工作階段親和性的單一伺服器或多部伺服器。 工作階段親和性也稱為黏性工作階段。 工作階段親和性表示來自用戶端的要求一律會路由至相同伺服器進行處理。

如需詳細資訊，請參閱 ASP.NET Core 中的記憶體內部快取和疑難排解 Azure 應用程式閘道工作階段親和性問題。

分散式快取

當應用程式裝載於雲端或伺服器陣列時，請使用分散式快取來儲存資料。 快取會跨處理要求的伺服器共用。 如果用戶端的快取資料可供使用，用戶端可以提交要求供群組中的任何伺服器處理。 ASP.NET Core 可搭配 SQL Server、Redis 和 NCache 分散式快取使用。

如需詳細資訊，請參閱 ASP.NET Core 中的分散式快取。

HybridCache

HybridCache API 會橋接 IDistributedCache 和 IMemoryCache API 中的一些間距。 HybridCache 是抽象類別，其預設實作會處理儲存至快取和從快取擷取的大部分層面。

功能

HybridCache 具有下列其他 API 沒有的功能：

• 適用於同處理序和跨處理序快取的整合 API。

  HybridCache 的設計目的是要取代現有的 IDistributedCache 和 IMemoryCache 使用方式，並提供簡單的 API 來新增快取程式碼。 如果應用程式具有 IDistributedCache 實作，則 HybridCache 服務會將其用於次要快取。 此雙層級快取策略可讓 HybridCache 提供記憶體內部快取的速度，以及分散式或持續性快取的持久性。

• 戳記保護。

  當經常使用的快取項目被撤銷，而太多要求嘗試同時重新填入相同的快取項目時，就會發生快取逃竄。 HybridCache 結合並行作業，可確保針對指定回應的所有要求都會等候第一個要求填入快取。

• 可設定的序列化。

  序列化設定為註冊服務的一部分，透過 WithSerializer 和 WithSerializerFactory 方法從 AddHybridCache 呼叫進行鏈結，支援類型特定和一般化序列化程式。 根據預設，服務會在內部處理 string 和 byte[]，並針對其他所有項目使用 System.Text.Json。 可以針對其他類型的序列化程式進行設定，例如 protobuf 或 XML。

若要查看 HybridCache API 的相對簡單性，請將使用它的程式碼與使用 IDistributedCache 的程式碼進行比較。 以下是使用 IDistributedCache 的呈現範例：

public class SomeService(IDistributedCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        var key = $"someinfo:{name}:{id}"; // Unique key for this combination.
        var bytes = await cache.GetAsync(key, token); // Try to get from cache.
        SomeInformation info;
        if (bytes is null)
        {
            // Cache miss; get the data from the real source.
            info = await SomeExpensiveOperationAsync(name, id, token);

            // Serialize and cache it.
            bytes = SomeSerializer.Serialize(info);
            await cache.SetAsync(key, bytes, token);
        }
        else
        {
            // Cache hit; deserialize it.
            info = SomeSerializer.Deserialize<SomeInformation>(bytes);
        }
        return info;
    }

    // This is the work we're trying to cache.
    private async Task<SomeInformation> SomeExpensiveOperationAsync(string name, int id,
        CancellationToken token = default)
    { /* ... */ }
}

每次都要做很多工作，包括序列化之類的事情。 在「快取遺漏」案例中，您最終可能會有多個並行執行緒、全部都有快取遺漏、全部都擷取基礎資料、全部序列化，以及全部將資料傳送至快取。

以下是使用 HybridCache 的對等程式碼：

public class SomeService(HybridCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        return await cache.GetOrCreateAsync(
            $"someinfo:{name}:{id}", // Unique key for this entry.
            async cancel => await SomeExpensiveOperationAsync(name, id, cancel),
            token: token
        );
    }
}

程式碼更簡單，而且程式庫會提供戳記保護，以及 IDistributedCache 沒有的其他功能。

相容性

HybridCache 程式庫支援舊版 .NET 執行階段，向下至 .NET Framework 4.7.2 和 .NET Standard 2.0。

其他資源

如需詳細資訊，請參閱以下資源：

• ASP.NET Core 中的 HybridCache 程式庫
• GitHub 問題 dotnet/aspnetcore #54647
• HybridCache 原始程式碼

快取標籤協助程式

使用快取標籤協助程式從 MVC 檢視或 Razor Page 快取內容。 快取標籤協助程式會使用記憶體內部快取來儲存資料。

如需詳細資訊，請參閱 ASP.NET Core MVC 中的快取標籤協助程式。

分散式快取標籤協助程式

使用分散式快取標籤協助程式，在分散式雲端或 Web 服務器陣列案例中，從 MVC 檢視或 Razor Page 快取內容。 分散式快取標籤協助程式會使用 SQL Server、Redis 或 NCache 來儲存資料。

如需詳細資訊，請參閱 ASP.NET Core 中的分散式快取標籤協助程式。

回應快取

回應快取中介軟體：

• 根據 HTTP 快取標頭啟用快取伺服器回應。 實作標準 HTTP 快取語意。 根據 Proxy 之類的 HTTP 快取標頭快取。
• 通常對 Razor Pages 之類的 UI 應用程式並不適用，因為瀏覽器通常會設定造成無法快取的要求標頭。 輸出快取可在 ASP.NET Core 7.0 和更新版本中取得，對 UI 應用程式有益。 使用輸出快取，設定會決定應該獨立於 HTTP 標頭快取的內容。
• 對於來自符合快取條件用戶端的公用 GET 或 HEAD API 要求可能會有幫助。

若要測試回應快取，請使用 Fiddler 或可明確設定要求標頭的其他工具。 明確設定標頭是測試快取的慣用方式。 如需詳細資訊，請參閱疑難排解。

輸出快取

輸出快取中介軟體可讓您快取 HTTP 回應。 輸出快取與回應快取不同，在以下方面：

• 快取行為可在伺服器上設定。

  回應快取行為是由 HTTP 標頭定義。 例如，當您使用 Chrome 或 Edge 瀏覽網站時，瀏覽器會自動傳送 Cache-control: max-age=0 標頭。 此標頭實際上會停用回應快取，因為伺服器會遵循用戶端所提供的指示。 即使伺服器有全新快取的回應，也會針對每個要求傳回新的回應。 使用輸出快取，用戶端不會覆寫您在伺服器上設定的快取行為。

• 快取儲存媒體可延伸。

  預設會使用記憶體。 回應快取僅限於記憶體。

• 您可以透過程式設計方式使選取的快取項目失效。

  回應快取對 HTTP 標頭的相依性可讓您使用少數選項來使快取項目失效。

• 資源鎖定可降低逃竄和驚群問題的風險。

  當經常使用的快取項目被撤銷，而太多要求嘗試同時重新填入相同的快取項目時，就會發生快取逃竄。 驚群問題類似：對尚不在快取項目中相同回應的要求激增。 資源鎖定可確保針對指定回應的所有要求都會等候第一個要求填入快取。 回應快取沒有資源鎖定功能。

• 快取重新驗證可將頻寬使用量降至最低。

  快取重新驗證表示伺服器可以傳回 304 Not Modified HTTP 狀態碼，而不是快取的回應本文。 此狀態碼會通知用戶端，對要求的回應與先前收到的回應沒有變更。 回應快取不會執行快取重新驗證。