Konfigurera en cachelagringsprincip
Optimala API-prestanda är avgörande för de flesta organisationer. Genom att använda en cache med samlade svar i Azure API Management kan du minska den tid för ett API att besvara anrop.
Anta att det finns ett behov av att brädspels-API:et ger snabbare svar på begäranden. Exempelvis begär användare ofta priser för olika storlekar av bräden till brädspel. API Management-principer kan påskynda svar genom att konfigurera en cache med förberedda svar. När en begäran tas emot från en användare kontrollerar API Management om det redan finns ett lämpligt svar i cacheminnet. Om det finns ett sådant svar kan det skickas till användaren utan att det behöver skapas på nytt från datakällan.
Här får du lära dig hur du konfigurerar en sådan cache.
Så kontrollerar du API Management-cachen
För att konfigurera en cache använder du en utgående princip som heter cache-store till att lagra svar. Du använder också en inkommande princip med namnet cache-lookup för att kontrollera om det finns ett cachelagrat svar för den aktuella begäran. Du kan se dessa två principer i exemplet nedan:
<policies>
<inbound>
<base />
<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<cache-store duration="60" />
<base />
</outbound>
</on-error>
<base />
</on-error>
</policies>
Det går också att lagra enskilda värden i cacheminnet i stället för ett fullständigt svar. Använd principen cache-store-value för att lägga till värdet med en ID-nyckel. Hämta värdet från cachen med hjälp av principen cache-lookup-value. Om du vill ta bort ett värde innan det upphör använder du principen cache-remove-value:
<policies>
<inbound>
<cache-lookup-value key="12345"
default-value="$0.00"
variable-name="boardPrice"
caching-type="internal" />
<base />
</inbound>
<backend>
<base />
</backend>
<outbound>
<cache-store-value key="12345"
value="$3.60"
duration="3600"
caching-type="internal" />
<base />
</outbound>
</on-error>
<base />
</on-error>
</policies>
Använda vary-by-taggar
Det är viktigt att se till att om du hanterar ett svar från cacheminnet är det relevant för den ursprungliga begäran. Men du vill också använda cacheminnet så mycket som möjligt. Anta exempelvis att brädspelets Stock Management-API fick en GET-begäran till följande URL och cachelagrade resultatet:
http://<boardgames.domain>/stock/api/product?partnumber=3416&customerid=1128
Den här begäran är avsedd att kontrollera lagernivåerna för en produkt med artikelnumret 3416. Kund-ID:t används av en separat princip och ändrar inte svaret. Efterföljande begäranden om samma artikelnummer kan hanteras från cacheminnet, så länge posten inte har upphört att gälla. Så långt är allt bra.
Anta nu att en annan kund begär samma produkt:
http://<boardgames.domain>/stock/api/product?partnumber=3416&customerid=5238
Som standard kan svaret inte betjänas från cachen eftersom kund-ID:t inte är samma.
Utvecklarna påpekar dock att kund-ID:t inte ändrar svaret. Det skulle vara effektivare om begäranden om samma produkt från olika kunder kunde returneras från cachen. Kunderna skulle då fortfarande se rätt information.
Om du vill ändra det här standardbeteendet använder du elementet vary-by-query-parameter i <cache-lookup> principen:
<policies>
<inbound>
<base />
<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal">
<vary-by-query-parameter>partnumber</vary-by-query-parameter>
</cache-lookup>
</inbound>
<backend>
<base />
</backend>
<outbound>
<cache-store duration="60" />
<base />
</outbound>
</on-error>
<base />
</on-error>
</policies>
Med den här principen lagrar cacheminnet och separata svar för varje produkt, eftersom de har olika artikelnummer. Cacheminnet lagrar inte separata svar för varje kund, eftersom frågeparametern inte visas.
Som standard undersöker Azure API Management inte HTTP-huvuden för att avgöra om ett cachelagrat svar är lämpligt för en viss begäran. Om ett huvud kan göra stor skillnad för ett svar använder du taggen <vary-by-header>. Arbeta med utvecklarteamet för att förstå hur varje API använder frågeparametrar och rubriker så att du kan bestämma vilka olika taggar som ska användas i din princip.
I taggen <cache-lookup> finns även vary-by-developer attributet, som krävs och är inställt på false som standard. När det här attributet är inställt på true undersöker API Management den prenumerationsnyckel som medföljer varje begäran. Den hanterar endast ett svar från cacheminnet om den ursprungliga begäran hade samma prenumerationsnyckel. Ange det här attributet till sant när varje användare ska se ett annat svar för samma URL. Om varje användargrupp ska se ett annat svar för samma URL anger du vary-by-developer-group attributet till true.
Använd extern cachelagring
API Management-instanser har vanligtvis en intern cache som används för att lagra förberedda svar på begäranden. Men om du vill kan du använda en Redis-kompatibel extern cache i stället. Ett möjligt system för extern cache som du kan använda är Azure Cache for Redis-tjänsten.
Du kan välja en extern cache av följande anledningar:
- Du vill undvika att cachen rensas när API Management-tjänsten uppdateras.
- Du vill ha större kontroll över cachekonfigurationen än vad som går med den interna cachen.
- Du vill cachelagrat mer data än vad som kan lagras i den interna cachen.
En annan anledning till att konfigurera en extern cache är att du vill använda cachelagring med prisnivån Förbrukning. Den här nivån följer serverlösa designprinciper och du bör använda den med serverlösa webb-API:er. Därför har den ingen intern cache. Om du vill använda cachelagring med en API Management-instans på förbrukningsnivån måste du använda en extern cache.