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 natrue
, 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.