Настройка политики кэширования
Оптимальная производительность API важна для большинства организаций. С помощью кэша скомпилированных ответов в службе управления API Azure можно сократить время, необходимое для ответа на вызовы API.
Предположим, что вам требуется API для настольных игр, чтобы быстрее предоставлять ответы на запросы. Например, пользователи часто запрашивают цены для различных размеров игровой доски. Политики управления API могут ускорить ответы, настроив кэш подготовленных ответов. При получении запроса от пользователя служба управления API проверяет, существует ли соответствующий ответ в кэше. Если существует, этот ответ можно отправить пользователю, не создавая его снова из источника данных.
Здесь вы узнаете, как настроить такой кэш.
Как управлять кэшем управления API
Чтобы настроить кэш, используйте политику исходящего трафика с именем cache-store, чтобы хранить ответы. Можно также использовать политику входящего трафика с именем cache-lookup, чтобы проверить, есть ли кэшированный ответ для текущего запроса. Можно просмотреть эти две политики в следующем примере:
<policies>
<inbound>
<base />
<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<cache-store duration="60" />
<base />
</outbound>
</on-error>
<base />
</on-error>
</policies>
Кроме того, можно хранить отдельные значения в кэше вместо полного ответа. Используйте политику cache-store-value, чтобы добавить значение с идентифицирующим ключом. Получите значение из кэша с помощью политики cache-lookup-value. Если вы хотите удалить значение до истечения срока его действия, используйте политику cache-remove-value:
<policies>
<inbound>
<cache-lookup-value key="12345"
default-value="$0.00"
variable-name="boardPrice"
caching-type="internal" />
<base />
</inbound>
<backend>
<base />
</backend>
<outbound>
<cache-store-value key="12345"
value="$3.60"
duration="3600"
caching-type="internal" />
<base />
</outbound>
</on-error>
<base />
</on-error>
</policies>
Использование тегов изменения
Очень важно убедиться, что предоставляемый вами ответ из кэша подходит для исходного запроса. Но при этом следует максимально использовать кэш. Предположим, что API управления запасами настольных игр получил запрос GET на следующий URL-адрес и кэшировал результат:
http://<boardgames.domain>/stock/api/product?partnumber=3416&customerid=1128
Этот запрос предназначен для проверки уровней запасов для товара с артикулом 3416. Идентификатор клиента используется отдельной политикой и не меняет ответ. Последующие запросы к тому же артикулу могут обслуживаться из кэша, пока срок действия записи не истечет. Пока все в порядке.
Теперь предположим, что другой клиент запрашивает тот же самый товар:
http://<boardgames.domain>/stock/api/product?partnumber=3416&customerid=5238
По умолчанию ответ невозможно обслужить из кэша, так как идентификатор клиента отличается.
Тем не менее разработчики указали, что идентификатор клиента не приводит к изменению ответа. Было бы эффективнее, если бы запросы на один товар от разных клиентов возвращались из кэша. Клиенты все равно получат правильные данные.
Чтобы изменить это поведение по умолчанию, используйте vary-by-query-parameter элемент в политике <cache-lookup> :
<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>partnumber</vary-by-query-parameter>
</cache-lookup>
</inbound>
<backend>
<base />
</backend>
<outbound>
<cache-store duration="60" />
<base />
</outbound>
</on-error>
<base />
</on-error>
</policies>
С этой политикой кэш будет хранить отдельные ответы для каждого товара, так как они имеют разные артикулы. Кэш не хранит отдельные ответы для каждого клиента, так как этот параметр запроса не указан.
По умолчанию Azure Управление API не проверяет заголовки HTTP, чтобы определить, подходит ли кэшированный ответ для данного запроса. Если заголовок значительно влияет на ответ, используйте тег <vary-by-header>. Пообщайтесь с командой разработчиков, чтобы понять, как каждый API использует параметры запроса и заголовки. Это поможет вам решить, какие теги изменений следует использовать в политике.
В теге <cache-lookup> также есть атрибут vary-by-developer, который является обязательным и имеет значение false по умолчанию. Если этот атрибут имеет значение true, служба "Управление API" проверяет ключ подписки, предоставленный с каждым запросом. Ответ из кэша предоставляется только в том случае, если в исходном запросе был такой же ключ подписки. Установите значение true, если каждый пользователь должен видеть разные ответы для одного и того же URL-адреса. Если каждая группа пользователей должна получать другой ответ для одного и того же URL-адреса, задайте для атрибута vary-by-developer-group значение true.
Использование внешнего кэша
Экземпляры службы управления API обычно имеют внутренний кэш, который используется для хранения подготовленных ответов на запросы. Однако, если вы предпочитаете, можно использовать внешний кэш, совместимый с Redis. Например, можно использовать службу "Кэш Azure для Redis".
Вы можете выбрать внешний кэш, так как:
- вы хотите избежать очистки кэша при обновлении службы управления API;
- вы хотите получить больший контроль над конфигурацией кэша, чем позволяет внутренний кэш;
- Вы хотите кэшировать больше данных, чем можно хранить во внутреннем кэше.
Еще одна причина настройки внешнего кэша заключается в том, что вы хотите использовать кэширование с ценовой категорией "Потребление". Этот уровень следует принципам бессерверного проектирования, и его следует использовать с бессерверными веб-API. По этой причине у него нет внутреннего кэша. Если вы хотите использовать кэширование с экземпляром Управление API на уровне потребления, необходимо использовать внешний кэш.