缓存概述

2025-09-19

适用于：所有 API 管理层级

在 Azure API 管理中配置缓存，以存储和检索对 API 请求和相关信息的响应。通过存储来自后端服务的响应，API 管理可以直接从缓存提供后续相同的请求，从而减少重复调用后端服务的需求。缓存可以提高 API 性能，减少后端负载，并通过 API 管理增强客户调用 API 的整体体验。

本文介绍 API 管理中的缓存选项，并重点介绍关键方案和配置注意事项。

重要

缓存需要缓存服务（作为 API 管理服务的一部分自动部署的内部缓存或客户部署的外部缓存）以及缓存策略的配置，以指定缓存应如何应用于 API 请求。

缓存服务选项

Azure API 管理提供以下缓存服务选项，以满足不同的性能和体系结构要求。

内部（内置）：内部（内置）缓存在所有 API 管理服务层（消耗层除外）中自动预配。内部缓存实现在经典层（开发人员层、基本层、标准层和 高级层）之间有所不同。详细了解如何使用内置缓存进行缓存。

外部缓存：为了增强性能和持久性，可以选择将与 Azure 托管 Redis 等外部 Redis 兼容的缓存配置为与任何 API 管理服务层或网关一起使用。详细了解如何使用 Azure 托管 Redis 或 Azure Redis 缓存设置外部缓存。

下表比较了内部和外部缓存的功能。

能力	内部	External
自动预配和管理	✔️	❌
新增费用	❌	✔️
自定义配置	❌	✔️
所有层和网关的可用性	在消费层或自托管网关中不可用	✔️
区域存储	缓存在 API 管理实例所在的区域中提供，并在缩放单元之间共享。在多区域部署中，每个区域都有自己的缓存。	取决于客户的偏好
每层限制	缓存大小因服务层而异	不受限制
多个 API 管理实例的共享访问	❌	✔️
数据预加载和清除支持	❌	✔️

缓存场景

在 Azure API 管理中使用缓存，以适用于类似于下表中情境的方案。

Scenario	Description	缓存类型	缓存不可用或连接丢失时的行为
优化客户端体验	加快客户端的重复请求处理速度。	内部或外部	后端为请求提供服务，如果缓存不可用，则必须处理完全负载。
控制成本和后端扩展	当后端系统未能承载完整流量时，应减少后端的负载和成本。	External	取决于缓存和服务配置。建议：选择具有最高可靠性和监视性能的缓存服务层。
元数据存储	使用 cache-store-value 在缓存中存储任意数据。	内部或外部	取决于缓存和服务配置。

注意事项:

在任何缓存方案中，客户都应考虑丢失缓存可用性或连接的可能性。 API 管理具有缓存可用性的“最佳努力”方法，因此，如果配置的缓存不可用，则会发生缓存未命中，默认情况下，请求会继续访问后端服务。
在 API 管理经典层中，内部缓存是易失性的，并且不会在服务更新之间保留。在服务更新期间，内部缓存在一个渐进过程中被清除，该过程一次最多涉及缓存的50%。

注释

可以配置服务更新设置（包括更新的维护窗口），以尽量减少对客户的潜在影响，例如内部缓存丢失。
如果已配置，外部缓存可以持久化，但客户负责确保可用性和连接。
作为保护后端服务免受在缓存不可用时可能会重载的流量高峰的最佳做法，建议在任何缓存查找策略之后立即配置速率限制策略（速率限制或按键限制）。

缓存策略

配置缓存策略以控制如何在 Azure API 管理中缓存和检索 API 响应。

默认情况下，在缓存策略中，如果已配置外部缓存，API 管理将优先使用外部缓存，否则将回退到内置缓存。
API 管理以对的形式提供缓存策略，如下表所示。在策略定义中，在 inbound 节配置缓存查找策略以检查缓存中的响应，并在 outbound 节配置缓存存储策略以将成功的响应存储到缓存中。

Policies	Description	Usage
cache-lookup / cache-store	- 从缓存中检索响应 - 在缓存请求中存储响应	- 用于检索来自缓存的完整 API 响应以获取相同的 `GET` 请求
缓存查找值 / 缓存存储值	- 从缓存中检索特定值 - 在缓存中存储特定值	- 用于具有特定缓存键的自定义缓存情境

小窍门

在缓存中存储条目的策略包括一个 duration 属性，用于指定缓存项的保留时间。
使用 cache-remove-value 从缓存中删除由键标识的特定值。

缓存策略示例

下面是 API 管理中缓存策略的基本示例。有关更多示例，请参阅缓存策略参考文章。

响应缓存

在内部缓存中缓存完整的 API 响应，以在没有后端调用的情况下提供相同的请求。在此示例中，缓存将响应存储 7 天。

<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 管理性能和缓存指标

Compartir a través de