Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

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

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Buforowanie to proces tymczasowego przechowywania danych w obszarze pamięci nazywanym pamięcią podręczną w celu wykorzystania ich w przyszłości. Buforowanie danych przynosi znaczne korzyści w zakresie wydajności, ponieważ:

umożliwia szybsze pobieranie danych,
skraca czas przetwarzania, ponieważ nie trzeba wielokrotnie generować danych,
zapobiega wysyłaniu żądań interfejsu API do serwerów backendu, a tym samym zmniejsza obciążenie na serwerach backendu,
umożliwia lepsze wykorzystanie zasobów systemu lub aplikacji,
skraca czas odpowiedzi interfejsów API.

Jeśli musimy często uzyskiwać dostęp do danych, które nie zmieniają się zbyt często, zdecydowanie zalecamy używanie pamięci podręcznej do ich przechowywania.

Apigee Edge umożliwia przechowywanie danych w pamięci podręcznej w czasie działania aplikacji w celu zapewnienia trwałości i szybszego pobierania. Funkcja buforowania jest dostępna dzięki zasadom PopulateCache, LookupCache, InvalidateCache i ResponseCache.

W tej sekcji omówimy zasadę ResponseCache. Zasada ResponseCache na platformie Apigee Edge umożliwia buforowanie odpowiedzi z serwerów backendu. Jeśli aplikacje klienckie wielokrotnie wysyłają żądania do tego samego zasobu backendu, a zasób jest okresowo aktualizowany, możemy buforować te odpowiedzi za pomocą tej zasady. Zasada ResponseCache pomaga w zwracaniu odpowiedzi z pamięci podręcznej, a tym samym zapobiega niepotrzebnemu przekazywaniu żądań do serwerów backendu.

Zasada ResponseCache:

zmniejsza liczbę żądań docierających do backendu,
zmniejsza przepustowość sieci,
zwiększa wydajność interfejsu API i skraca czas odpowiedzi.

Antywzorzec

Zasada ResponseCache domyślnie umożliwia buforowanie odpowiedzi HTTP z dowolnym kodem stanu. Oznacza to, że można buforować zarówno odpowiedzi o powodzeniu, jak i o błędzie.

Oto przykładowa zasada ResponseCache 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 ResponseCache w konfiguracji domyślnej buforuje odpowiedzi o błędzie. Nie zalecamy jednak buforowania odpowiedzi o błędzie bez dokładnego przemyślenia negatywnych konsekwencji, ponieważ:

Scenariusz 1. Awarie występują przez tymczasowy, nieznany okres, a my możemy nadal wysyłać odpowiedzi o błędzie z powodu buforowania, nawet po rozwiązaniu problemu.
LUB
Scenariusz 2. Awarie będą obserwowane przez określony czas, a następnie będziemy musieli zmodyfikować kod, aby uniknąć buforowania odpowiedzi po rozwiązaniu problemu.

Wyjaśnimy to, omawiając te 2 scenariusze bardziej szczegółowo.

Scenariusz 1. Tymczasowa awaria backendu lub zasobu

Załóżmy, że awaria serwera backendu jest spowodowana jedną z tych przyczyn:

Tymczasowy problem z siecią.
Serwer backendu jest bardzo zajęty i przez pewien czas nie może odpowiadać na żądania .
Żądany zasób backendu może być tymczasowo usunięty lub niedostępny.
Serwer backendu odpowiada wolno z powodu długiego czasu przetwarzania przez pewien czas, itp.

We wszystkich tych przypadkach awarie mogą występować przez nieznany czas, a następnie możemy zacząć otrzymywać odpowiedzi o powodzeniu. Jeśli buforujemy odpowiedzi o błędzie, możemy nadal wysyłać je do użytkowników, nawet jeśli problem z serwerem backendu został rozwiązany.

Scenariusz 2. Długotrwała lub stała awaria backendu lub zasobu

Załóżmy, że wiemy, że awaria backendu będzie trwać 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 usunięty lub niedostępny przez 24 godziny z powodu nagłej awarii witryny, problemów ze skalowaniem, konserwacji, aktualizacji itp.

Dzięki tym informacjom możemy odpowiednio ustawić czas wygaśnięcia pamięci podręcznej w zasadzie ResponseCache, aby nie buforować odpowiedzi o błędzie przez dłuższy czas. Gdy serwer lub zasób backendu będzie ponownie dostępny, będziemy musieli zmodyfikować zasadę, aby uniknąć buforowania odpowiedzi o błędzie. Jeśli bowiem wystąpi tymczasowa lub jednorazowa awaria serwera backendu, zbuforujemy odpowiedź i będziemy mieć problem opisany w scenariuszu 1 powyżej.

Wpływ

Buforowanie odpowiedzi o błędzie może spowodować, że będą one wysyłane nawet po rozwiązaniu problemu na serwerze backendu .
Użytkownicy mogą poświęcić dużo czasu na rozwiązywanie problemu, nie wiedząc, że jest on spowodowany buforowaniem odpowiedzi o błędzie z serwera backendu.

Sprawdzona metoda

Nie przechowuj odpowiedzi o błędzie w pamięci podręcznej odpowiedzi. Upewnij się, że element <ExcludeErrorResponse> ma wartość true w zasadzie ResponseCache, aby zapobiec buforowaniu odpowiedzi o błędzie, jak pokazano w poniższym fragmencie kodu. W tej konfiguracji buforowane będą tylko odpowiedzi na domyślne kody powodzenia od 200 do 205 (chyba że kody powodzenia zostaną 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 określonego powodu musisz buforować odpowiedzi o błędzie, możesz określić maksymalny lub dokładny czas, przez który będzie występować awaria (jeśli to możliwe):
- Ustaw odpowiedni czas wygaśnięcia, aby nie buforować odpowiedzi o błędzie dłużej niż czas, przez który może występować awaria.
- Użyj zasady ResponseCache, aby buforować odpowiedzi o błędzie bez elementu <ExcludeErrorResponse>.
Zrób to tylko wtedy, gdy masz pewność, że awaria serwera backendu nie jest krótkotrwała ani tymczasowa.
Apigee nie zaleca buforowania odpowiedzi 5xx z serwerów backendu.