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

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X.
Informacje

Zapisywanie w pamięci podręcznej polega na tym, że dane są tymczasowo przechowywane w pamięci podręcznej, aby można ją było wykorzystać w przyszłości. Przechowywanie danych w pamięci podręcznej ma znaczny wpływ na wydajność, ponieważ:

  • Umożliwia szybsze pobieranie danych
  • Skraca czas przetwarzania przez unikanie ciągłego ponownego generowania danych
  • Zapobiega wysyłaniu żądań interfejsu API do serwerów backendu, a tym samym zmniejsza obciążenie serwerów backendu
  • Umożliwia lepsze wykorzystanie zasobów systemu/aplikacji
  • Skrócenie czasu odpowiedzi interfejsów API

Gdy musimy często uzyskiwać dostęp do danych, które nie zmieniają się zbyt często, zdecydowanie 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 trwałość i szybsze pobieranie. Funkcja buforowania jest dostępna za pomocą zasad PopulateCache, zasad LookupCache, InvalidateCache i ResponseCache.

W tej sekcji przyjrzyjmy się zasadom buforowania odpowiedzi. Zasada pamięci podręcznej odpowiedzi na platformie Apigee Edge umożliwia zapisywanie w pamięci podręcznej odpowiedzi z serwerów backendu. Jeśli aplikacje klienckie wysyłają żądania do tego samego zasobu backendu wielokrotnie, a zasób jest aktualizowany okresowo, możemy wykorzystać tę zasadę w pamięci podręcznej. Zasada buforowania odpowiedzi pomaga zwracać odpowiedzi z pamięci podręcznej, a tym samym unika niepotrzebnie przekazywania żądań do serwerów backendu.

Zasada buforowania odpowiedzi:

  • Zmniejsza liczbę żądań docierających do backendu
  • Zmniejsza przepustowość sieci
  • Przyspieszenie działania interfejsu API i skrócenie czasu odpowiedzi

Antywzór

Zasada ResponseCache domyślnie pozwala buforować odpowiedzi HTTP z dowolnym możliwym kodem stanu. Oznacza to, że w pamięci podręcznej mogą być przechowywane zarówno odpowiedzi zakończone powodzeniem, jak i błędem.

Oto przykładowa zasada buforowania 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 zapisuje w pamięci podręcznej odpowiedzi dotyczące błędów w konfiguracji domyślnej. Nie zalecamy jednak zapisywania odpowiedzi z błędami w pamięci podręcznej bez odpowiedniej analizy ich negatywnych skutków, ponieważ:

  • Scenariusz 1. Błędy występują przez jakiś czas, nieznany okres i możemy nadal wysyłać odpowiedzi błędów z powodu buforowania, nawet po rozwiązaniu problemu.

    LUB

  • Scenariusz 2. Błędy będą rejestrowane przez ustalony czas, a potem trzeba będzie zmodyfikować kod, aby uniknąć zapisywania odpowiedzi w pamięci podręcznej po rozwiązaniu problemu.

Wyjaśnimy to bardziej szczegółowo, biorąc pod uwagę te 2 scenariusze.

Scenariusz 1. Tymczasowy błąd backendu/zasobu

Weź pod uwagę, że awarie serwera backendu mają jedną z tych przyczyn:

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

We wszystkich tych przypadkach błędy mogą wystąpić z nieznanego okresu, a my możemy zacząć otrzymywać skuteczne odpowiedzi. Jeśli zapisujemy odpowiedzi z błędami w pamięci podręcznej, możemy nadal wysyłać użytkownikom odpowiedzi o błędach, mimo że problem z serwerem backendu został rozwiązany.

Scenariusz 2. Dłuższy lub rozwiązany błąd backendu/zasobu

Wiadomo, że błąd w backendzie występuje tylko przez określony czas. Na przykład wiesz, że:

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

    LUB

  • Serwer backendu jest usuwany/niedostępny na 24 godziny z powodu nagłej awarii witryny, problemów ze skalowaniem, konserwacji, uaktualnienia itp.

Dzięki tym informacjom możemy odpowiednio ustawić czas wygaśnięcia pamięci podręcznej w zasadzie buforowania odpowiedzi, aby nie przechowywać odpowiedzi z błędami przez dłuższy czas. Gdy jednak serwer lub zasób backendu będą ponownie dostępne, trzeba będzie zmodyfikować zasadę, aby uniknąć zapisywania odpowiedzi w pamięci podręcznej z odpowiedziami o błędach. Dzieje się tak, ponieważ w przypadku wystąpienia tymczasowej lub jednorazowej awarii po stronie serwera backendu zapiszemy odpowiedź w pamięci podręcznej, co spowoduje rozwiązanie problemu opisanego w scenariuszu 1 powyżej.

Wpływ

  • Buforowanie odpowiedzi z błędami może powodować wysyłanie odpowiedzi o błędach nawet po rozwiązaniu problemu na serwerze backendu
  • Użytkownicy mogą poświęcać dużo czasu na rozwiązanie problemu, nie wiedząc, że jest on spowodowany zapisywaniem odpowiedzi błędu z serwera backendu w pamięci podręcznej

Sprawdzona metoda

  • Nie przechowuj odpowiedzi o błędach w pamięci podręcznej odpowiedzi. Sprawdź, czy element <ExcludeErrorResponse> w zasadzie ResponseCache jest ustawiony na true, aby zapobiec zapisywaniu w pamięci podręcznej odpowiedzi o błędach, jak pokazano w poniższym fragmencie kodu. W tej konfiguracji w pamięci podręcznej przechowywane są tylko odpowiedzi na domyślne kody powodzenia od 200 do 205 (chyba że kody powodzenia zostały zmodyfikowane).
    <!-- /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ś powodu musisz zapisać w pamięci podręcznej odpowiedzi o błędzie, możesz określić maksymalny lub dokładny czas obserwowania błędu (jeśli to możliwe):
    • Ustaw odpowiednio czas ważności, aby mieć pewność, że odpowiedzi o błędzie nie będą przechowywane w pamięci podręcznej dłużej niż przez okres, po którym występuje błąd.
    • Użyj zasady ResponseCache, aby buforować odpowiedzi z błędem bez elementu <ExcludeErrorResponse>.

    Zrób to tylko wtedy, gdy masz absolutną pewność, że awaria serwera backendu nie jest związana z krótkimi ani tymczasowymi okresami.

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