Oglądasz dokumentację Apigee Edge.
Wyświetl dokumentację Apigee X.

Buforuje dane z zasobu backendu, zmniejszając liczbę żądań wysyłanych do zasobu. Gdy aplikacje wysyłają żądania do tego samego identyfikatora URI, możesz użyć tej zasady, by zwracać odpowiedzi z pamięci podręcznej, zamiast przekazywać je do serwera backendu. Zasada ResponseCache może zwiększyć wydajność interfejsu API dzięki zmniejszeniu opóźnień i ruchu w sieci.
Prawdopodobnie będzie to najlepsze rozwiązanie, gdy dane backendu używane przez interfejs API są aktualizowane tylko okresowo. Załóżmy na przykład, że masz interfejs API, który udostępnia dane pogodowe odświeżane tylko co 10 minut. Używając metody ResponseCache do zwracania odpowiedzi z pamięci podręcznej między odświeżeniami, możesz zmniejszyć liczbę żądań docierających do backendu. Zmniejsza to też liczbę przeskoków sieci.
Krótkotrwałe przechowywanie danych w pamięci podręcznej warto wziąć pod uwagę za pomocą zasad dotyczących zapełniania pamięci podręcznej. Ta zasada jest używana w połączeniu z zasadami dotyczącymi pamięci podręcznej wyszukiwania (do odczytywania wpisów w pamięci podręcznej) i zasadami dotyczącymi unieważniania pamięci podręcznej (w przypadku unieważniania wpisów).
Obejrzyj ten film, aby zapoznać się z wprowadzeniem do zasad dotyczących pamięci podręcznej odpowiedzi.
Sample
10-minutowa pamięć podręczna
Ten przykład pokazuje, jak odpowiedzi w pamięci podręcznej są przechowywane przez 10 minut.
Wyobraź sobie, że masz interfejs API pod tym adresem URL:
http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778
Używasz parametru zapytania w
jako klucza pamięci podręcznej. Apigee Edge sprawdza wartość parametru zapytania w
po otrzymaniu żądania. Jeśli w pamięci podręcznej znajduje się prawidłowa (wygasła) odpowiedź, klient otrzymuje odpowiedź z pamięci podręcznej.
Teraz wyobraź sobie, że masz skonfigurowaną zasadę ResponseCache w następujący sposób.
<ResponseCache name="ResponseCache"> <CacheKey> <KeyFragment ref="request.queryparam.w" /> </CacheKey> <ExpirySettings> <TimeoutInSeconds>600</TimeoutInSeconds> </ExpirySettings> </ResponseCache>
Gdy pierwszy raz serwer proxy interfejsu API otrzyma wiadomość z prośbą o podanie określonego adresu URL, odpowiedź zostanie zapisana w pamięci podręcznej. Przy drugim żądaniu w ciągu 10 minut następuje wyszukiwanie w pamięci podręcznej – odpowiedź z pamięci podręcznej jest zwracana do aplikacji bez przekazywania żądania do usługi backendu.
http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778
Pomiń wyszukiwanie w pamięci podręcznej
Poniższy przykład pokazuje, jak pominąć wyszukiwanie w pamięci podręcznej i ją odświeżyć. Zobacz też ten film na temat korzystania z SkipCacheLookup.
Opcjonalny warunek SkipCacheLookup (jeśli jest skonfigurowany) jest oceniany w ścieżce żądania. Jeśli warunek przyjmie wartość Prawda, wyszukiwanie w pamięci podręcznej zostanie pominięte, a pamięć podręczna odświeżona.
Typowym zastosowaniem odświeżania pamięci podręcznej jest warunek, który definiuje konkretny nagłówek HTTP, przez który warunek otrzymuje wartość Prawda. Skryptową aplikację kliencką można skonfigurować w taki sposób, aby okresowo wysyłał żądanie z odpowiednim nagłówkiem HTTP, co bezpośrednio powoduje odświeżenie pamięci podręcznej odpowiedzi.
Wyobraźmy sobie na przykład wywołanie interfejsu API dostępne pod tym adresem URL:
'http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778' -H "bypass-cache:true"
Teraz wyobraź sobie następujące zasady ResponseCache skonfigurowane na tym serwerze proxy. Pamiętaj, że warunek pomijania pamięci podręcznej ma wartość Prawda.
<ResponseCache name="ResponseCache"> <CacheKey> <KeyFragment ref="request.queryparam.w" /> </CacheKey> <!-- Explicitly refresh the cached response --> <SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup> <ExpirySettings> <TimeoutInSeconds>600</TimeoutInSeconds> </ExpirySettings> </ResponseCache>
Więcej informacji o warunkach znajdziesz w artykule Zmienne i warunki przepływu.
Dokumentacja elementu
Odwołanie do elementu opisuje elementy i atrybuty zasad.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1"> <DisplayName>Response Cache 1</DisplayName> <Properties/> <CacheKey> <Prefix/> <KeyFragment ref="request.uri" /> </CacheKey> <Scope>Exclusive</Scope> <ExpirySettings> <ExpiryDate/> <TimeOfDay/> <TimeoutInSeconds ref="flow.variable.here">300</TimeoutInSeconds> </ExpirySettings> <CacheResource>cache_to_use</CacheResource> <CacheLookupTimeoutInSeconds/> <ExcludeErrorResponse/> <SkipCacheLookup/> <SkipCachePopulation/> <UseAcceptHeader/> <UseResponseCacheHeaders/> </ResponseCache>
Atrybuty <ResponseCache>
<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">
Tabela poniżej opisuje atrybuty wspólne dla wszystkich elementów nadrzędnych zasad:
Atrybut | Opis | Domyślnie | Obecność |
---|---|---|---|
name |
Wewnętrzna nazwa zasady. Wartość atrybutu Opcjonalnie użyj elementu |
Nie dotyczy | Wymagany |
continueOnError |
Ustaw wartość Ustaw wartość |
fałsz | Opcjonalnie |
enabled |
Ustaw jako Ustaw zasadę |
prawda | Opcjonalnie |
async |
Ten atrybut został wycofany. |
fałsz | Wycofano |
Element <DisplayName>
Używaj atrybutu name
tak, aby oznaczyć zasadę w edytorze proxy interfejsu zarządzania inną nazwą w języku naturalnym.
<DisplayName>Policy Display Name</DisplayName>
Domyślnie |
Nie dotyczy Jeśli pominiesz ten element, zostanie użyta wartość atrybutu |
---|---|
Obecność | Opcjonalnie |
Typ | Ciąg znaków |
Element <CacheKey>
Konfiguruje unikalny wskaźnik fragmentu danych przechowywanych w pamięci podręcznej.
Klucze pamięci podręcznej mogą mieć maksymalnie 2 KB.
<CacheKey> <Prefix>string</Prefix> <KeyFragment ref="variable_name" /> <KeyFragment>literal_string</KeyFragment> </CacheKey>
Domyślne: |
Nie dotyczy |
Obecność: |
Wymagany |
Typ: |
Nie dotyczy |
<CacheKey>
tworzy nazwę każdego fragmentu danych przechowywanych w pamięci podręcznej.
Klucz jest często ustawiany na podstawie wartości z nagłówków encji lub parametrów zapytania. W takim przypadku atrybut ref elementu określa zmienną zawierającą wartość klucza.
W czasie działania na początku wartości <KeyFragment>
są dołączane wartością elementu <Scope>
lub <Prefix>
. Na przykład taki klucz powoduje wyświetlenie w pamięci podręcznej klucza UserToken__apiAccessToken__
<value_of_client_id>:
<CacheKey> <Prefix>UserToken</Prefix> <KeyFragment>apiAccessToken</KeyFragment> <KeyFragment ref="request.queryparam.client_id" /> </CacheKey>
Elementu <CacheKey>
używasz w połączeniu z elementami <Prefix>
i <Scope>
. Więcej informacji znajdziesz w artykule Praca z kluczami pamięci podręcznej.
Element <CacheLookupTimeoutInSeconds>
Określa liczbę sekund, po których nieudane wyszukiwanie pamięci podręcznej zostanie uznane za pominięte. Jeśli tak się stanie, przepływ zostanie wznowiony na ścieżce brakującej pamięci podręcznej.
<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>
Domyślne: |
30 |
Obecność: |
Opcjonalnie |
Typ: |
Liczba całkowita |
Element <CacheResource>
Określa pamięć podręczną, w której mają być przechowywane wiadomości. Pomiń ten element, aby używać dołączonej pamięci podręcznej. Aby określić możliwość usuwania danych administracyjnych zawartych w pamięci podręcznej, musisz podać nazwę CacheResource według nazwy. Więcej informacji na ten temat znajdziesz w artykule Pamięci podręczne.
<CacheResource>cache_to_use</CacheResource>
Domyślne: |
Nie dotyczy |
Obecność: |
Opcjonalnie |
Typ: |
Ciąg znaków |
Więcej informacji o konfigurowaniu pamięci podręcznej znajdziesz w artykule Tworzenie i edytowanie pamięci podręcznej środowiska.
Element <CacheKey>/<KeyFragment>
Określa wartość, która powinna być uwzględniona w kluczu pamięci podręcznej, tworząc przestrzeń nazw do dopasowywania żądań do odpowiedzi w pamięci podręcznej.
<KeyFragment ref="variable_name"/> <KeyFragment>literal_string</KeyFragment>
Domyślne: |
Nie dotyczy |
Obecność: |
Opcjonalnie |
Typ: |
Nie dotyczy |
Może to być klucz (podana przez Ciebie nazwa statyczna) lub wartość (dynamiczny wpis odwołujący się do zmiennej). Wszystkie określone fragmenty łącznie (oraz prefiks) są łączone, aby utworzyć klucz pamięci podręcznej.
<KeyFragment>apiAccessToken</KeyFragment> <KeyFragment ref="request.queryparam.client_id" />
Elementu <KeyFragment>
używasz w połączeniu z elementami <Prefix>
i <Scope>
. Więcej informacji znajdziesz w artykule Praca z kluczami pamięci podręcznej.
Atrybuty
Atrybut | Typ | Domyślna | Wymagany | Opis |
---|---|---|---|---|
ref | tekst | Nie |
Zmienna, z której ma zostać pobrana wartość. Nie należy używać, jeśli ten element zawiera wartość literałową. |
Element <CacheKey>/<Prefiks>
Określa wartość używaną jako prefiks klucza pamięci podręcznej.
<Prefix>prefix_string</Prefix>
Domyślne: |
Nie dotyczy |
Obecność: |
Opcjonalnie |
Typ: |
Ciąg znaków |
Używaj tej wartości zamiast <Scope>
, gdy chcesz określić własną wartość, a nie <Scope>
. Jeśli zasada jest zdefiniowana, <Prefix>
dodaje na początku wartość klucza pamięci podręcznej dla wpisów zapisanych w pamięci podręcznej. Wartość elementu <Prefix>
zastępuje wartość elementu <Scope>
.
Elementu <Prefix>
używasz w połączeniu z elementami <CacheKey>
i <Scope>
. Więcej informacji znajdziesz w artykule Praca z kluczami pamięci podręcznej.
Element <ExcludeErrorResponse>
Obecnie ta zasada domyślnie zapisuje w pamięci podręcznej odpowiedzi HTTP dowolny możliwy kod stanu. To oznacza, że zarówno powodzenie, jak i błąd pojawiają się w pamięci podręcznej. Na przykład odpowiedzi z kodami stanu 2xx i 3xx są domyślnie przechowywane w pamięci podręcznej.
Ustaw ten element na wartość true
, jeśli nie chcesz zapisywać w pamięci podręcznej odpowiedzi docelowych z kodami stanu błędu HTTP. Jeśli ten element jest prawdziwy, tylko odpowiedzi z kodami stanu 200–205 będą przechowywane w pamięci podręcznej. To jedyne kody stanu HTTP, które Edge liczy jako kody powodzenia. Nie możesz zmienić tego powiązania.
Więcej informacji na temat wzorców pamięci podręcznej odpowiedzi, w których ten element jest przydatny, znajdziesz w tym poście na karcie Społeczność.
Uwaga: w przyszłej wersji (do ustalenia) domyślne ustawienie tego elementu zmieni się na „true”. Aby dowiedzieć się więcej, zobacz Informacje o wersji Apigee.
<ExcludeErrorResponse>true</ExcludeErrorResponse>
Domyślne: |
fałsz |
Obecność: |
Opcjonalnie |
Typ: |
Wartość logiczna |
Element <ExpirySettings>
Określa, kiedy wpis w pamięci podręcznej ma wygasnąć. Jeśli ta opcja jest dostępna, <TimeoutInSeconds>
zastępuje zarówno <TimeOfDay>
, jak i <ExpiryDate>
.
<ExpirySettings> <TimeOfDay ref="time_variable">expiration_time</TimeOfDay> <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds> <ExpiryDate ref="date_variable">expiration_date</ExpiryDate> </ExpirySettings>
Domyślne: |
Nie dotyczy |
Obecność: |
Wymagany |
Typ: |
Nie dotyczy |
Element <ExpirySettings>/<ExpiryDate>
Określa datę wygaśnięcia wpisu w pamięci podręcznej. Użyj formularza mm-dd-yyyy
.
Jeśli ta opcja jest dostępna, element równorzędny <TimeoutInSeconds>
zastępuje <ExpiryDate>
.
<ExpirySettings> <ExpiryDate ref="{date_variable}">expiration_date</ExpiryDate> </ExpirySettings>
Domyślne: |
Nie dotyczy |
Obecność: |
Opcjonalnie |
Typ: |
Ciąg znaków |
Atrybuty
<ExpiryDate ref="" />
Atrybut | Opis | Domyślna | Obecność | Typ |
---|---|---|---|---|
ref |
Zmienna, z której ma zostać pobrana wartość. Nie należy używać, jeśli ten element zawiera wartość literałową. |
Nie dotyczy | Opcjonalnie | Ciąg znaków |
Element <ExpirySettings>/<TimeOfDay>
Godzina, o której wpis w pamięci podręcznej powinien wygasnąć. Użyj formularza hh:mm:ss
.
Jeśli ta opcja jest dostępna, element równorzędny <TimeoutInSeconds>
zastępuje <TimeOfDay>
.
Podaj godzinę w formacie GG:mm:ss, gdzie HH to godzina na zegarze 24-godzinnym. np. 14:30:00 po południu i 14:30.
W zależności od pory dnia domyślny język i strefa czasowa będą się różnić w zależności od miejsca działania kodu (tego, co będzie wiadomo po skonfigurowaniu zasady). Informacje o konfigurowaniu ustawień regionalnych znajdziesz w artykule Tworzenie i edytowanie pamięci podręcznej środowiska.
<ExpirySettings> <TimeOfDay ref="time_variable">expiration_time</TimeOfDay> </ExpirySettings>
Domyślne: |
Nie dotyczy |
Obecność: |
Opcjonalnie |
Typ: |
Ciąg znaków |
Atrybuty
Atrybut | Opis | Domyślna | Obecność | Typ |
---|---|---|---|---|
ref | Zmienna z datą ważności. | Nie dotyczy | Opcjonalnie | Ciąg znaków |
Element <ExpirySettings>/<TimeoutInSec>
Liczba sekund, po której wpis w pamięci podręcznej ma wygasnąć.
Element <ExpirySettings>/<TimeoutInSeconds>
Liczba sekund, po której wpis w pamięci podręcznej ma wygasnąć. Jeśli ten element jest obecny, zastępuje jego elementy równorzędne, <TimeOfDay>
i <ExpiryDate>
.
<ExpirySettings> <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds> </ExpirySettings>
Uwaga: podaj domyślną wartość limitu czasu, która zostanie użyta, jeśli odesłanie nie uzyska wartości z pola duration_variable
.
Domyślne: |
Nie dotyczy |
Obecność: |
Opcjonalnie |
Typ: |
Ciąg znaków |
Atrybuty
Atrybut | Opis | Domyślna | Obecność | Typ |
---|---|---|---|---|
ref | Zmienna z czasem oczekiwania. |
Nie dotyczy
|
Opcjonalnie | Ciąg znaków |
Element <Scope>
Obliczenie służące do tworzenia prefiksu klucza pamięci podręcznej, gdy element <Prefix>
nie zawiera elementu <CacheKey>
.
<Scope>scope_enumeration</Scope>
Domyślne: |
Tylko dla subskrybentów |
Obecność: |
Opcjonalnie |
Typ: |
Ciąg znaków |
Ustawienie <Scope>
określa klucz pamięci podręcznej, który będzie dołączany na podstawie wartości <Scope>
. Na przykład klucz pamięci podręcznej miałby taką postać, gdy ustawiony jest zakres Exclusive
: orgName__envName__apiProxyName__deployedRevisionNumber__proxy|TargetName__ [serializedCacheKey ].
Jeśli element <Prefix>
występuje w <CacheKey>
, zastępuje wartość elementu <Scope>
. Prawidłowe wartości obejmują poniższe wyliczenia.
Elementu <Scope>
używasz w połączeniu z elementami <CacheKey>
i <Prefix>
. Więcej informacji znajdziesz w artykule Praca z kluczami pamięci podręcznej.
Dopuszczalne wartości
Wartość zakresu | Opis |
---|---|
Global |
Klucz pamięci podręcznej jest wspólny dla wszystkich serwerów proxy interfejsu API wdrożonych w środowisku. Klucz pamięci podręcznej jest dołączany na początku formName __ envName __. Jeśli zdefiniujesz wpis |
Application |
Jako prefiksu używana jest nazwa serwera proxy interfejsu API. Klucz pamięci podręcznej jest dołączany na początku w postaci orgName__envName__apiProxyName. |
Proxy |
Jako prefiksu używana jest konfiguracja ProxyEndpoint. Klucz pamięci podręcznej jest dołączany na początku w formacie orgName__envName__apiProxyName__deployedRevisionNumber__proxyEndpointName . |
Target |
Jako prefiksu używana jest konfiguracja TargetEndpoint. Klucz pamięci podręcznej dołączany na początku orgName__envName__apiProxyName__deployedRevisionNumber__targetEndpointName . |
Exclusive |
Domyślny: Jest to najbardziej precyzyjne, dlatego pozwala zminimalizować ryzyko kolidacji przestrzeni nazw w pamięci podręcznej. Prefiks ma 1 z 2 form:
Klucz pamięci podręcznej dołączany na początku orgName__envName__apiProxyName__deployedRevisionNumber__proxyNameITargetName Pełny tekst może na przykład wyglądać tak: apifactory__test__weatherapi__16__default__apiAccessToken |
Element <SkipCacheLookup>
Definiuje wyrażenie, które w przypadku oceny „prawda” w czasie działania wskazuje, że wyszukiwanie pamięci podręcznej powinno zostać pominięte, a pamięć podręczna – odświeżana. Zobacz też ten film o korzystaniu z SkipCacheLookup.
<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>
Domyślne: |
Nie dotyczy |
Obecność: |
Opcjonalnie |
Typ: |
Ciąg znaków |
W przykładzie poniżej, jeśli zmienna pomijania pamięci podręcznej ma wartość Prawda w nagłówku przychodzącym, wyszukiwanie pamięci podręcznej jest pomijane, a pamięć podręczna jest odświeżana.
<SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>
Element <SkipCachepop>
Definiuje wyrażenie, które w czasie działania ocenia jako „prawda”, aby zapis w pamięci podręcznej był pomijany. Obejrzyj też ten film na temat korzystania z populacji Pomiń pamięć podręczną.
<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>
Domyślne: |
Nie dotyczy |
Obecność: |
Opcjonalnie |
Typ: |
Ciąg znaków |
Na przykład taki kod pomijałby zapisywanie w pamięci podręcznej, jeśli kod stanu odpowiedzi to 400 lub więcej:
<SkipCachePopulation>response.status.code >= 400</SkipCachePopulation>
Element <UseAcceptHeader>
Ustaw wartość true
, aby dołączyć do klucza klucz pamięci podręcznej wpisu odpowiedzi z wartościami Akceptuj nagłówki.
Podczas obliczania klucza pamięci podręcznej Edge używa nagłówków żądań Accept
, Accept-Encoding
, Accept-Language
i Accept-Charset
. Takie podejście uniemożliwia klientowi uzyskanie typu mediów, o który nie prosił.
Możesz na przykład sprawdzić, czy 2 żądania pochodzą z tego samego adresu URL – pierwsze żądanie akceptuje plik gzip, a drugi – nie. Pierwsze żądanie zostanie zapisane w pamięci podręcznej, a wpis w pamięci podręcznej (prawdopodobnie) będzie odpowiedzią gzip. Drugie żądanie odczyta wartość z pamięci podręcznej, a potem może zwrócić wpis gzip klientowi, który nie może odczytać gzip.
Więcej informacji znajdziesz w sekcji Konfigurowanie klucza pamięci podręcznej.
<UseAcceptHeader>false</UseAcceptHeader>
Domyślne: |
fałsz |
Obecność: |
Opcjonalnie |
Typ: |
Wartość logiczna |
Element <UseResponseCacheHeaders>
Ustaw wartość true
, aby nagłówki odpowiedzi HTTP były brane pod uwagę podczas określania czasu życia danych (TTL) w pamięci podręcznej. Gdy tak się dzieje, Edge rozważa wartości poniższych nagłówków odpowiedzi, porównując je z wartościami ustawionymi przez zasadę <ExpirySettings>
podczas określania czasu życia danych:
Cache-Control s-maxage
Cache-Control max-age
Expires
Więcej informacji znajdziesz w sekcji Ustawianie czasu wygaśnięcia wpisu w pamięci podręcznej.
<UseResponseCacheHeaders>false</UseResponseCacheHeaders>
Domyślne: |
fałsz |
Obecność: |
Opcjonalnie |
Typ: |
Wartość logiczna |
Zastosowanie
Maksymalny rozmiar każdego obiektu z pamięci podręcznej to 512 KB. Szczegółowe informacje o przetwarzaniu pamięci podręcznej przez Edge znajdziesz w artykule Wewnętrzne dane pamięci podręcznej.
Dzięki konfiguracji w zasadzie ResponseCache możesz ustawić dla przeglądarki Edge dołączanie nagłówków odpowiedzi HTTP podczas ustawiania kluczy wygaśnięcia dostępu do pamięci podręcznej i kluczy pamięci podręcznej. W tej sekcji możesz używać zasady z nagłówkami do zarządzania czasem wygaśnięcia i kluczami pamięci podręcznej.
Więcej informacji o tym, jak Edge obsługuje nagłówki odpowiedzi za pomocą zasady ResponseCache, znajdziesz w artykule Obsługa nagłówków odpowiedzi HTTP.
Ustawianie okresu ważności wpisu w pamięci podręcznej
Podobnie jak w przypadku zasad dotyczących wypełniania pamięci podręcznej, za pomocą elementu <ExpirySettings>
możesz ustawić datę ważności wpisu w pamięci podręcznej odpowiedzi (czas życia). W zasadzie ResponseCache mogą być też ustawione nagłówki Edge, które pojawiają się, gdy są dostępne.
Aby używać nagłówków odpowiedzi, ustaw wartość elementu <UseResponseCacheHeaders>
na true. To ustawienie powoduje, że Edge rozważa nagłówki odpowiedzi, porównuje je z wartością ustawioną w <ExpirySettings>
, a potem używa najniższej wartości z obu. Rozważając nagłówki odpowiedzi, Edge wybiera dostępną wartość w sposób opisany poniżej:
Załóżmy na przykład, że odpowiedź jest przechowywana w pamięci podręcznej wraz z tymi wartościami:
- Brak wartości parametru
Cache-Control s-maxage
- Wartość
Cache-Control max-age
: 300 - Data w ciągu 3 dni:
Expires
- Wartość
<ExpirySettings>
TimeoutInSeconds
wynosi 600.
W tym przypadku użyjemy wartości Cache-Control
max-age
TTL, ponieważ jest ona niższa od wartości <ExpirySettings>
, ponieważ nie ma wartości Cache-Control s-maxage
(która ma pierwszeństwo przed wartością max-age
).
Konfigurowanie klucza pamięci podręcznej
Tak jak w przypadku ogólnych zasad dotyczących pamięci podręcznej, takich jak Population Cache policy, uzupełnij element ResponseCache o elementy <CacheKey>
i <Scope>
, by skonfigurować tworzenie klucza pamięci podręcznej dla pozycji pamięci podręcznej. Za pomocą ResponseCache możesz też zwiększyć przydatność kluczy pamięci podręcznej, dołączając do nagłówków nagłówki Akceptuj odpowiedzi.
Ogólne informacje o konfigurowaniu kluczy pamięci podręcznej znajdziesz w tym artykule. Informacje o używaniu nagłówków znajdziesz w artykule <UseAcceptHeader>
.
Informacje o szyfrowaniu pamięci podręcznej
Brzegowy w chmurze publicznej: pamięć podręczna jest szyfrowana tylko w organizacjach, w których włączono PCI i HIPAA. Szyfrowanie dla tych organizacji jest skonfigurowane podczas obsługi administracyjnej organizacji.
Zmienne przepływu
Podczas wykonywania zasady ResponseCache wypełnione są poniższe wstępnie zdefiniowane zmienne przepływu. Więcej informacji o zmiennych procesu znajdziesz w artykule o zmiennych.
Zmienne | Typ | Uprawnienia | Opis |
---|---|---|---|
responsecache.{policy_name}.cachename |
Ciąg znaków | Tylko do odczytu | Zwraca pamięć podręczną używaną w zasadzie |
responsecache.{policy_name}.cachekey |
Ciąg znaków | Tylko do odczytu | Zwraca użyty klucz |
responsecache.{policy_name}.cachehit |
Wartość logiczna | Tylko do odczytu | Wartość „prawda”, jeśli wykonanie zasady się powiedzie |
responsecache.{policy_name}.invalidentry |
Wartość logiczna | Tylko do odczytu | Wartość „prawda”, jeśli wpis w pamięci podręcznej jest nieprawidłowy |
Kody błędów
W tej sekcji opisano komunikaty o błędach i zmienne przepływu skonfigurowane po uruchomieniu tej zasady. Ta informacja jest ważna, gdy opracowujesz reguły awarii serwera proxy. Więcej informacji znajdziesz w artykułach Co musisz wiedzieć o błędach zasad i Obsługa błędów.
Prefiks kodu błędu
Nie dotyczy
Błędy w czasie wykonywania
Ta zasada nie powoduje błędów w czasie działania.
Błędy wdrażania
Te błędy mogą wystąpić, gdy wdrażasz serwer proxy zawierający tę zasadę.
Nazwa błędu | Przyczyna | Napraw |
---|---|---|
InvalidTimeout |
Jeśli element <CacheLookupTimeoutInSeconds> zasady ResponseCache ma wartość ujemną, wdrożenie serwera proxy interfejsu API nie powiedzie się. |
build |
InvalidCacheResourceReference |
Ten błąd występuje, jeśli element <CacheResource> w zasadzie ResponseCache ma nazwę, która nie istnieje w środowisku, w którym wdrażany jest serwer proxy interfejsu API. |
build |
ResponseCacheStepAttachmentNotAllowedReq |
Ten błąd występuje, jeśli ta sama zasada ResponseCache jest dołączona do wielu ścieżek żądań w dowolnym przepływie serwera proxy interfejsu API. | build |
ResponseCacheStepAttachmentNotAllowedResp |
Ten błąd występuje, jeśli ta sama zasada ResponseCache jest dołączona do wielu ścieżek odpowiedzi w dowolnym przepływie proxy interfejsu API. | build |
InvalidMessagePatternForErrorCode |
Ten błąd występuje, jeśli element <SkipCacheLookup> lub <SkipCachePopulation> w zasadzie ResponseCache zawiera nieprawidłowy warunek. |
build |
CacheNotFound |
Ten błąd występuje, jeśli konkretna pamięć podręczna wymieniona w komunikacie o błędzie nie została utworzona w określonym komponencie procesora wiadomości. | build |
Zmienne błędów
Nie dotyczy
Przykładowa odpowiedź na błąd
Nie dotyczy
Schemat
Każdy typ zasady jest zdefiniowany za pomocą schematu XML (.xsd
). Informacje o schematach zasad są dostępne na GitHubie.