快取概觀

適用於：所有 API 管理層

在 Azure API 管理中設定快取，以儲存和擷取 API 要求和相關資訊的回應。藉由儲存來自後端服務的回應，API 管理可以直接從快取提供後續相同的要求，減少重複呼叫後端服務的需求。快取可以改善 API 效能、減少後端負載，並增強客戶透過 API 管理呼叫 API 的整體體驗。

本文說明 API 管理中的快取選項，並強調重要案例和設定考慮。

這很重要

快取需要快取服務（自動部署為 API 管理服務一部分的內部快取，或由您部署的外部快取）和快取原則的設定，以指定快取應該如何套用至 API 要求。

快取服務選項

Azure API 管理提供下列快取服務選項，以符合不同的效能和架構需求。

內部（內建） ：內部（內建）快取會自動佈建在所有 API 管理服務層級（取用層除外）中。內部快取實作在傳統層（開發人員、基本、標準和進階）和 v2 層（基本 v2、 標準 v2 和 進階 v2）之間有所不同。 v2 層中的內建快取提供增強的可靠性。深入了解如何使用內建快取進行快取。
外部快取：若要增強效能和持續性，您可以選擇性地設定外部 Redis 相容快取，例如 Azure 受控 Redis，以搭配任何 API 管理服務層級或閘道使用。深入瞭解如何使用 Azure 受控 Redis 設定外部快取。

下表比較了內部和外部快取的功能。

能力	內部	External
自動佈建和管理	✔️	❌
增加成本	❌	✔️
自訂設定	❌	✔️
所有層級和閘道的可用性	不適用於消費層或自我代管閘道	✔️
區域儲存	快取在與 API 管理執行個體相同的區域中提供，並在縮放單位之間共用。在多區域部署中，每個區域都有自己的快取。	取決於客戶的喜好
持久性儲存	在 v2 層中持續存在。在傳統層（開發人員、基本、標準和進階）中，發生服務更新時，快取內容不會保留。	✔️
每個層級的限制	快取大小會因服務層級而異	不限
多個 API 管理實例的共用存取	❌	✔️
語意快取支援	❌	✔️
資料預先載入和清除支援	❌	✔️

快取案例

針對下表所示的案例，使用 Azure API 管理中的快取。

Scenario	Description	快取類型	快取可用性或連線能力遺失時的行為
優化客戶體驗	加快客戶的重複請求處理速度。	內部或外部	後端會負責處理要求，如果快取無法使用，則必須處理全部負載。
控制成本和後端擴展	當後端未針對完整流量進行擴展時，減少後端負載和成本。	External	取決於快取和服務組態。建議：選擇具有最高可靠性的快取服務層級，並監控其性能表現。
中繼資料存放區	使用 cache-store-value 將任意資料儲存在快取中。	內部或外部	取決於快取和服務組態。

Considerations:

在任何快取案例中，請考慮快取可用性或連線性遺失的可能性。 API 管理會使用「最佳努力」的方法來確保快取的可用性。如果設定的快取無法使用，則會發生快取遺漏，而且預設情況下，要求會繼續到後端服務。
在 API 管理傳統層中，內部快取是變動性的，而且不會在服務更新之間持續存在。在服務更新期間，內部快取會逐步清除，一次最多涉及 50% 的快取。

備註

您可以設定服務更新設定，包括更新的維護時段，以將潛在的客戶影響降到最低，例如內部快取的丟失。
如果您設定外部快取，它可以是持續性的，但您有責任確保可用性和連線能力。
若要保護後端服務免於在快取無法使用時可能超載的流量尖峰，請在任何快取查閱策略之後立即設定速率限制策略（速率限制或按金鑰限制）。

快取原則

設定快取原則，以控制在 Azure API 管理中快取和擷取 API 回應的方式。

根據預設，在快取原則中，API 管理會使用外部快取（如果已設定），否則會回復至內建快取。
API 管理會提供成對的快取原則，如下表所示。在原則定義中，在區 inbound 段中設定快取查閱原則以檢查快取的回應，並在區 outbound 段中設定快取存放區原則，以將成功的回應儲存在快取中。

Policies	Description	Usage
快取查詢 / 快取儲存	- 從快取擷取回應 - 將回應儲存在快取要求中	- 用於從快取擷取相同 `GET` 要求的完整 API 回應
快取查詢值 / 快取儲存值	- 從快取擷取特定值 - 在快取中儲存特定值	- 用於具有特定快取金鑰的自訂快取案例
azure-openai-semantic-cache-lookup / azure-openai-semantic-cache-store	- 檢查 Azure OpenAI API 要求的快取中是否存在語意上類似的回應 - 儲存 Azure OpenAI API 要求的回應	- 用於擷取 Azure OpenAI 聊天完成 API 要求的類似回應
LLM 語義緩存查找 / LLM 語義緩存存儲	- 檢查 LLM API 請求的快取中是否存在語意相似的回應 - 儲存 LLM API 請求的回應	- 用於從 LLM 聊天完成 API 要求中取出類似回應

小提示

將項目儲存在快取中的原則包括一個 duration 屬性，用於指定快取項目持續多久。
使用 cache-remove-value 從快取中移除由 key 識別的特定值。

快取原則範例

以下是 API 管理中的快取原則基本範例。如需更多範例，請參閱快取原則參考文章。

回應快取

將完整的 API 回應快取在內部快取中，以提供相同的請求，而無需後端呼叫。在此範例中，快取會儲存回應七天。

<policies>
    <inbound>
        <base />
        <cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal" >
            <vary-by-query-parameter>version</vary-by-query-parameter>
        </cache-lookup>
    </inbound>
    <outbound>
        <cache-store duration="604800" />
        <base />
    </outbound>
</policies>

值缓存

快取特定資料值，以便在多個請求中重複使用。

<policies>
    <inbound>
        <cache-lookup-value key="user-preferences" default-value="none" variable-name="preferences" />
        <choose>
            <when condition="@(context.Variables["preferences"].ToString() == "none")">
                <!-- Load preferences from backend -->
                <send-request mode="new" response-variable-name="prefsResponse">
                    <set-url>https://backend.api/user/preferences</set-url>
                </send-request>
                <cache-store-value key="user-preferences" value="@(((IResponse)context.Variables["prefsResponse"]).Body.As<string>())" duration="1800" />
            </when>
        </choose>
    </inbound>
</policies>

速率限制保護

最佳實務是將快取查閱與速率限制結合，以保護後端服務。

<policies>
    <inbound>
        <cache-lookup-value key="@("data-" + context.Request.IpAddress)" variable-name="cachedData" />
        <choose>
            <when condition="@(!context.Variables.ContainsKey("cachedData"))">
                <rate-limit calls="10" renewal-period="60" />
                <!-- Proceed to backend -->
            </when>
            <otherwise>
                <!-- Return cached data without rate limiting -->
                <return-response>
                    <set-body>@((string)context.Variables["cachedData"])</set-body>
                </return-response>
            </otherwise>
        </choose>
    </inbound>
</policies>

安全性考慮

敏感資料：避免緩存包含敏感或個人資訊的回應
快取金鑰：確保快取金鑰不會在記錄或診斷中公開敏感資訊
存取控制：外部快取需要適當的網路安全和存取控制
加密：使用 TLS/SSL 連線至外部快取執行個體

深入瞭解 API 管理中的快取原則
使用 Azure 受控 Redis 設定外部快取
進階案例下的自訂快取範例
監視 API 管理效能和快取計量

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-10-31