我使用 API 管理和外部 Azure Redis 缓存来缓存访问外部服务的响应。我需要提供一种机制,通过从服务器重新获取数据来使缓存的响应无效 - 进而使用新的响应更新缓存。
当缓存的响应过期或收到带有 Cache-Control: Must-revalidate
header 的新请求时,我当前的策略(如下所示)会从服务器接收最新数据。同样,当收到 header 时,我想用新响应更新缓存的响应。我在概念上或在我的政策中是否遗漏了任何内容?
<policies>
<inbound>
<base />
<set-backend-service id="apim-generated-policy" backend-id="func-myapp-dev-001" />
<set-variable name="mustRevalidate" value="@(context.Request.Headers.GetValueOrDefault("Cache-Control","").Contains("must-revalidate"))" />
<choose>
<when condition="@(context.Variables.GetValueOrDefault<bool>("mustRevalidate") == false)">
<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" allow-private-response-caching="true" />
</when>
</choose>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
<set-header name="Cached-At" exists-action="override">
<value>@(System.DateTime.Now.ToString())</value>
</set-header>
<cache-store duration="360" />
</outbound>
<on-error>
<base />
</on-error>
</policies>
最佳答案
问题是 <cache-store>
没有<cache-lookup>
就活不下去。 <cache-lookup>
不仅从缓存中获取缓存值,而且它也是 <cache-store>
的一种配置。 。您可以在跟踪中亲眼看到这一点。当您使用 Control-Cache: must-revalidate
调用 API 时 header ,<cache-lookup>
不会因为您的<when>
而被触发政策还<cache-store>
不幸的是,不会被触发。在日志中您将看到消息:
cache-store (0.019 ms) "Corresponding cache-lookup policy was not applied. Skipping cache-store."
所以你已经得到它了。跳过<cache-lookup>
将从后端获取新的响应,但之后不会缓存它以供将来的请求。
至于如何实现你想要的。
我已经检查了两次,但不幸的是 <cache-lookup>
没有跳过基于参数的查找的选项。
也在考虑不同的方法。我认为这可以与 <cache-lookup-value>
一起使用政策。一开始,根据你的must-revalidate
参数如果设置为 true 您可以删除缓存的值。然后就可以正常进行了。最困难的部分是考虑可以根据请求生成缓存 key 的机制。 APIM 在 cache-store
中所做的同样的事情。不同请求之间的 key 必须是唯一的,但同一请求的 key 必须相同 - 与缓存的工作原理完全相同。 APIM 应用于缓存键的模式是这样的(您可以检查跟踪):
"cacheKey": "{apimName}.{apiId};{revision};{backendurl with all query parameters}"
来 self 的 API 的示例:
"cacheKey": "my-apim.azure-api.net.1_weatherbit-io;rev=1.2432_get-current-city_id-city_id-key-key_4_https_api.weatherbit.io_443_/v2.0/current?city_id=4487042"
一旦你有了一些智能的 key 生成,我想你就可以开始了,最终的解决方案可能如下所示:
<policies>
<inbound>
<set-variable name="cacheKey" value="@{
return ""; // here implement some smart key generation based on the request parameters from context.
}" />
<set-variable name="mustRevalidate" value="@(context.Request.Headers.GetValueOrDefault("Cache-Control","").Contains("must-revalidate"))" />
<choose>
<when condition="@(context.Variables.GetValueOrDefault<bool>("mustRevalidate") == true)">
<cache-remove-value key="@(context.Variables.GetValueOrDefault<string>("cacheKey"))" />
</when>
</choose>
<cache-lookup-value key="@(context.Variables.GetValueOrDefault<string>("cacheKey"))" variable-name="cachedResponse" />
<choose>
<when condition="@(context.Variables.GetValueOrDefault<JObject>("cachedResponse") != (JObject)null)">
<return-response>
<set-header name="Content-Type" exists-action="override">
<value>application/json; charset=utf-8</value>
</set-header>
<set-body>@{
return context.Variables.GetValueOrDefault<JObject>("cachedResponse").ToString();
}</set-body>
</return-response>
</when>
</choose>
<base />
</inbound>
<backend>
<base />
</backend>
<outbound>
<cache-store-value key="@(context.Variables.GetValueOrDefault<string>("cacheKey"))" value="@(context.Response.Body.As<JObject>(preserveContent: true))" duration="30" />
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
当然,这仅缓存响应,如果您还想缓存 header ,则必须实现如何存储它的机制,然后何时将其返回到<return-response>
内,如何将其解析为标题和正文。我希望您能看到这个解决方案的缺点是什么,您需要自己实现所有内容。您无法再使用 <cache-lookup>
的内置功能和<cache-store>
。但同时你有更多的自由,可以实现你想要的。不管怎样,祝你好运。
<cache-store-value>
政策有caching-type
属性。您可以使用它将缓存更改为外部缓存。
关于Azure API 管理刷新缓存的响应,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/68167922/