Антипаттерн: кэшировать ответы об ошибках

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

Кэширование — это процесс временного хранения данных в области хранения, называемой кешем, для дальнейшего использования. Кэширование данных обеспечивает значительный выигрыш в производительности, поскольку оно:

  • Позволяет быстрее получать данные
  • Сокращает время обработки, избегая повторной регенерации данных.
  • Предотвращает попадание запросов API на внутренние серверы и тем самым снижает нагрузку на внутренние серверы.
  • Позволяет лучше использовать ресурсы системы/приложения.
  • Улучшает время отклика API

Всякий раз, когда нам приходится часто обращаться к некоторым данным, которые не меняются слишком часто, мы настоятельно рекомендуем использовать кеш для хранения этих данных.

Apigee Edge предоставляет возможность хранить данные в кеше во время выполнения для обеспечения устойчивости и более быстрого извлечения. Функция кэширования доступна через политику PopulateCache , политику LookupCache , политику InvalidateCache и политику ResponseCache .

В этом разделе давайте рассмотрим политику кэша ответов. Политика кэширования ответов на платформе Apigee Edge позволяет кэшировать ответы от серверных серверов. Если клиентские приложения неоднократно отправляют запросы к одному и тому же внутреннему ресурсу и ресурс периодически обновляется, то мы можем кэшировать эти ответы, используя эту политику. Политика кэширования ответов помогает возвращать кэшированные ответы и, следовательно, позволяет избежать ненужной пересылки запросов на внутренние серверы.

Политика кэша ответов:

  • Уменьшает количество запросов, поступающих на серверную часть
  • Уменьшает пропускную способность сети
  • Улучшает производительность API и время отклика.

Антипаттерн

Политика ResponseCache позволяет по умолчанию кэшировать HTTP-ответы с любым возможным кодом состояния. Это означает, что ответы об успехах и ошибках могут кэшироваться.

Вот пример политики кэша ответов с конфигурацией по умолчанию:

<!-- /antipatterns/examples/1-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServer ResponseCache</DisplayName>
  <CacheKey>
    <Key Fragment ref="request.uri" /></CacheKey>
    <Scope>Exclusive</Scope>
    <ExpirySettings>
      <TimeoutInSec ref="flow.variable.here">600</TimeoutInSec>
    </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
</ResponseCache>

Политика кэширования ответов кэширует ответы об ошибках в конфигурации по умолчанию. Однако не рекомендуется кэшировать ответы об ошибках, не задумываясь о неблагоприятных последствиях, поскольку:

  • Сценарий 1. Сбои происходят в течение временного неизвестного периода, и мы можем продолжать отправлять ответы об ошибках из-за кэширования даже после устранения проблемы.

    ИЛИ

  • Сценарий 2. Сбои будут наблюдаться в течение фиксированного периода времени, затем нам придется изменить код, чтобы избежать кэширования ответов, как только проблема будет устранена.

Давайте объясним это, рассмотрев эти два сценария более подробно.

Сценарий 1. Временный сбой серверной части/ресурса.

Учтите, что сбой на внутреннем сервере произошел по одной из следующих причин:

  • Временный сбой в сети
  • Внутренний сервер чрезвычайно занят и не может отвечать на запросы в течение временного периода.
  • Запрошенный внутренний ресурс может быть удален или недоступен в течение временного периода времени.
  • Внутренний сервер отвечает медленно из-за длительного времени обработки в течение временного периода и т. д.

Во всех этих случаях сбои могут возникать в течение неизвестного периода времени, а затем мы можем начать получать успешные ответы. Если мы кэшируем ответы об ошибках, мы можем продолжать отправлять ответы об ошибках пользователям, даже если проблема с внутренним сервером была устранена.

Сценарий 2. Длительный или фиксированный сбой серверной части/ресурса.

Учтите, что мы знаем, что сбой в серверной части происходит в течение фиксированного периода времени. Например, вы знаете, что либо:

  • Определенный серверный ресурс будет недоступен в течение 1 часа.

    ИЛИ

  • Внутренний сервер удален/недоступен в течение 24 часов из-за внезапного сбоя сайта, проблем с масштабированием, обслуживания, обновления и т. д.

Используя эту информацию, мы можем соответствующим образом установить время истечения срока действия кэша в политике кэша ответов, чтобы не кэшировать ответы об ошибках в течение более длительного времени. Однако, как только внутренний сервер/ресурс снова станет доступен, нам придется изменить политику, чтобы избежать кэширования ответов об ошибках. Это связано с тем, что в случае временного/однократного сбоя на внутреннем сервере мы кэшируем ответ и в конечном итоге столкнемся с проблемой, описанной в сценарии 1 выше.

Влияние

  • Кэширование ответов об ошибках может привести к отправке ответов об ошибках даже после того, как проблема была решена на внутреннем сервере.
  • Пользователи могут потратить много усилий на устранение причины проблемы, не зная, что она вызвана кэшированием ответов об ошибках с внутреннего сервера.

Лучшая практика

  • Не храните ответы об ошибках в кэше ответов. Убедитесь, что для элемента <ExcludeErrorResponse> установлено значение true в политике ResponseCache, чтобы предотвратить кэширование ответов об ошибках, как показано в приведенном ниже фрагменте кода. При такой конфигурации будут кэшироваться только ответы для кодов успеха по умолчанию от 200 до 205 (если коды успеха не изменены). 
    <!-- /antipatterns/examples/1-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServerResponseCache</DisplayName>
  <CacheKey>
    <KeyFragment ref="request.uri" />
  </CacheKey>
  <Scope>Exclusive</Scope>
  <ExpirySettings>
    <TimeoutinSec ref="flow.variable.here">600</TimeoutinSec>
  </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
  <ExcludeErrorResponse>true</ExcludeErrorResponse>
</ResponseCache>
  • Если по какой-то конкретной причине у вас есть необходимость кэшировать ответы об ошибках, вы можете определить максимальную/точную продолжительность времени, в течение которого будет наблюдаться сбой (если это возможно):
    • Установите время истечения срока действия соответствующим образом, чтобы гарантировать, что вы не кэшируете ответы об ошибках дольше, чем время, в течение которого можно увидеть сбой.
    • Используйте политику ResponseCache для кэширования ответов об ошибках без элемента <ExcludeErrorResponse> .

    Делайте это только в том случае, если вы абсолютно уверены, что сбой внутреннего сервера не является кратковременным .

  • Apigee не рекомендует кэшировать ответы 5xx с внутренних серверов.