Antywzór: odpowiedzi na błędy w pamięci podręcznej

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Pamięć podręczna to proces tymczasowego przechowywania danych w obszarze nazywanym pamięcią podręczną na przyszłość. odwołania. Zapisywanie danych w pamięci podręcznej znacznie zwiększa wydajność, ponieważ:

  • Umożliwia szybsze pobieranie danych
  • Skraca czas przetwarzania dzięki uniknięciu nieustannego generowania danych
  • Uniemożliwia wysyłaniu żądań do interfejsu API do serwerów backendu, zmniejszając w ten sposób serwery backendu
  • Umożliwia lepsze wykorzystanie zasobów systemu/aplikacji
  • Skraca czas odpowiedzi interfejsów API

Gdy musimy często korzystać z danych, które nie zmieniają się zbyt często, zalecamy przechowywanie tych danych w pamięci podręcznej.

Apigee Edge umożliwia przechowywanie danych w pamięci podręcznej w czasie działania, co zapewnia ich trwałość i szybsze działanie pobieranie danych. Funkcję buforowania udostępnia zasada PopulationCache. Zasada szeregowania pamięci podręcznej, zasada VerifyCache i zasada pamięci podręcznej odpowiedzi.

W tej sekcji przyjrzymy się zasadom pamięci podręcznej odpowiedzi. Zasada pamięci podręcznej odpowiedzi w Apigee Edge umożliwia buforowanie odpowiedzi z serwerów backendu. Jeśli aplikacje klienckie wielokrotnie wysyła żądania do tego samego zasobu backendu, co powoduje jego aktualizację możemy je okresowo zapisywać w pamięci podręcznej, korzystając z tej zasady. Zasada pamięci podręcznej odpowiedzi pomaga zwracać odpowiedzi z pamięci podręcznej, a tym samym pozwala uniknąć przekazywania żądań do serwerów backendu.

Zasada pamięci podręcznej odpowiedzi:

  • Zmniejsza liczbę żądań docierających do backendu
  • Zmniejsza przepustowość sieci
  • Zwiększa wydajność interfejsu API i czas odpowiedzi

Antywzór

Zasada ResponseCache umożliwia buforowanie odpowiedzi HTTP w pamięci podręcznej z dowolnym kodem stanu. domyślnie. Oznacza to, że w pamięci podręcznej mogą być przechowywane zarówno odpowiedzi powodzenia, jak i błędów.

Oto przykładowa zasada pamięci podręcznej odpowiedzi z konfiguracją domyślną:

<!-- /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>

Zasada pamięci podręcznej odpowiedzi domyślnie zapisuje w pamięci podręcznej odpowiedzi na błędy konfiguracji. Nie zalecamy jednak zapisywania odpowiedzi w pamięci podręcznej w pamięci podręcznej bez przemyślenia nad negatywnymi konsekwencjami, ponieważ:

  • Sytuacja 1: awarie występują przez pewien tymczasowy, nieznany okres i może nadal wysyłać odpowiedzi na błędy ze względu na buforowanie nawet po rozwiązaniu problemu

    LUB

  • Scenariusz 2: błędy są obserwowane przez określony czas, Gdy problem zostanie rozwiązany, będziemy musieli zmienić kod, aby uniknąć zapisywania odpowiedzi w pamięci podręcznej.

Przyjrzyjmy się temu 2 scenariuszom bardziej szczegółowo.

Scenariusz 1. Tymczasowa awaria backendu/zasobu

Weź pod uwagę, że awaria serwera backendu może mieć jedną z tych przyczyn:

  • Tymczasowa awaria sieci
  • Serwer backendu jest bardzo zajęty i nie może odpowiedzieć na żądania kropka
  • Żądany zasób backendu może zostać usunięty lub niedostępny przez pewien czas
  • Serwer backendu odpowiada wolno z powodu długiego czasu przetwarzania. itp.

We wszystkich tych przypadkach awarie mogą wystąpić przez nieznany okres, a następnie możemy rozpocząć otrzymywanie pomyślnych odpowiedzi. Jeśli odpowiedzi na błędy zostaną zapisane w pamięci podręcznej, możemy nadal wysyłać odpowiadania użytkownikom, mimo że problem z serwerem backendu został rozwiązany.

Scenariusz 2. Przedłużona lub naprawiona awaria backendu/zasobu

Weź pod uwagę, że wiemy, że awarie backendu występują od dłuższego czasu. Przykład: wiesz, że:

  • Określony zasób backendu będzie niedostępny przez 1 godzinę

    LUB

  • serwer backendu jest usunięty/niedostępny na 24 godziny z powodu nagłej awarii witryny, problemy ze skalowaniem, konserwacja, uaktualnienie itp.

Dzięki tym informacjom możemy odpowiednio ustawić czas wygaśnięcia pamięci podręcznej w pamięci podręcznej odpowiedzi , dzięki czemu nie przechowujemy odpowiedzi o błędach w pamięci podręcznej przez dłuższy czas. Jednak gdy Serwer/zasób backendu jest ponownie dostępny, trzeba będzie zmodyfikować zasadę, aby uniknąć buforowania odpowiedzi na błędy. Dzieje się tak, ponieważ w przypadku wystąpienia tymczasowej/jednorazowej awarii backendu serwer, odpowiedź będzie przechowywana w pamięci podręcznej, aż do rozwiązania problemu przedstawionego w scenariuszu 1 powyżej.

Wpływ

  • Odpowiedzi na błędy z pamięci podręcznej mogą spowodować wysłanie odpowiedzi na błąd nawet po wystąpieniu problemu rozpoznano na serwerze backendu
  • Użytkownicy mogą poświęcać wiele czasu na rozwiązanie problemu, nie wiedząc, że jest to spowodowane zapisywaniem odpowiedzi w pamięci podręcznej z serwera backendu.

Sprawdzona metoda

  • Nie zapisuj odpowiedzi na błędy w pamięci podręcznej odpowiedzi. Upewnij się, że parametr Element <ExcludeErrorResponse> jest ustawiony na true w: Zasada ResponseCache, aby zapobiec zapisywaniu odpowiedzi błędów w pamięci podręcznej, jak pokazano w poniższym kodzie . Na w przypadku tej konfiguracji będą wyświetlane tylko odpowiedzi na domyślne kody powodzenia 200–205 (chyba że kody powodzenia) są zapisywane w pamięci podręcznej. 
    <!-- /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>
  • Jeśli z jakiegoś konkretnego powodu wymagasz zapisywania odpowiedzi na błędy w pamięci podręcznej, może określić maksymalny/dokładny czas, przez jaki błąd będzie występował (jeśli możliwe):
    • Ustaw odpowiednio czas wygaśnięcia, aby odpowiedzi o błędach nie były zapisywane w pamięci podręcznej jest dłuższy niż czas, przez jaki błąd jest widoczny.
    • Użyj zasady ResponseCache, aby zapisać w pamięci podręcznej odpowiedzi na błędy bez <ExcludeErrorResponse> element.

    Zrób to tylko wtedy, gdy masz absolutną pewność, że awaria serwera backendu nie dotyczy krótki/tymczasowy okres.

  • Apigee nie zaleca buforowania odpowiedzi 5xx z serwerów backendu.