Overzicht van caching

Van toepassing op: Alle API Management-lagen

Configureer caching in Azure API Management om reacties op API-aanvragen en gerelateerde informatie op te slaan en op te halen. Door reacties van back-endservices op te slaan, kan API Management opeenvolgende identieke aanvragen rechtstreeks vanuit de cache verwerken, waardoor de noodzaak om de back-endservice herhaaldelijk aan te roepen, wordt verminderd. Caching kan de API-prestaties verbeteren, de back-endbelasting verminderen en de algehele ervaring verbeteren van klanten die API's aanroepen via API Management.

In dit artikel worden de cacheopties in API Management uitgelegd en worden belangrijke scenario's en configuratieoverwegingen gemarkeerd.

Opties voor cacheservice

Azure API Management biedt de volgende cacheserviceopties om te voldoen aan verschillende prestatie- en architectuurvereisten.

• Intern (ingebouwd): de interne (ingebouwde) cache wordt automatisch ingericht in alle API Management-servicelagen (met uitzondering van de verbruikslaag ). De interne cache-implementatie verschilt tussen de klassieke lagen (Developer, Basic, Standard en Premium) en de v2-lagen (Basic v2, Standard v2 en Premium v2). De ingebouwde cache in de v2-lagen biedt verbeterde betrouwbaarheid. Meer informatie over opslaan in cache met de ingebouwde cache.

• Externe cache: voor verbeterde prestaties en persistentie configureert u eventueel een externe Redis-compatibele cache, zoals Azure Managed Redis, voor gebruik met elke API Management-servicelaag of -gateway. Meer informatie over het instellen van een externe cache met Azure Managed Redis.

In de volgende tabel worden de mogelijkheden van de interne en externe cache vergeleken.

Cachingscenario's

Gebruik caching in Azure API Management voor scenario's zoals die in de volgende tabel.

Considerations:

• Overweeg in elk cachescenario de mogelijkheid om de beschikbaarheid of connectiviteit van de cache te verliezen. API Management maakt gebruik van een 'best effort'-benadering voor de beschikbaarheid van de cache. Als een geconfigureerde cache niet beschikbaar is, treden er cache-misses op en worden aanvragen standaard doorgestuurd naar de back-endservice.

• In de klassieke API Management-lagen is de interne cache vluchtig en blijft deze niet behouden tussen service-updates. Tijdens een service-update wordt de interne cache gewist in een geleidelijk proces dat maximaal 50% van de cache tegelijk omvat.

  Opmerking

  U kunt instellingen voor service-updates configureren, inclusief een onderhoudsvenster voor updates, om mogelijke gevolgen van klanten te minimaliseren, zoals verlies van de interne cache.

• Als u een externe cache configureert, kan deze persistent zijn, maar u bent verantwoordelijk voor het garanderen van beschikbaarheid en connectiviteit.

• Als u de back-endservice wilt beschermen tegen verkeerspieken die deze kunnen overbelasten wanneer er geen cache beschikbaar is, configureert u een beleid voor snelheidsbeperking (frequentielimiet of frequentielimiet per sleutel) direct na een cachezoekbeleid.

Cachebeleid

Configureer cachebeleid om te bepalen hoe API-antwoorden in de cache worden opgeslagen en opgehaald in Azure API Management.

• Standaard gebruikt API Management in cachebeleid een externe cache als deze is geconfigureerd; anders wordt teruggevallen op de ingebouwde cache.

• API Management biedt cachebeleid in paren, zoals wordt weergegeven in de volgende tabel. Configureer in een beleidsdefinitie een cachezoekbeleid in de inbound sectie om te controleren op reacties in de cache en een cacheopslagbeleid in de outbound sectie om geslaagde antwoorden in de cache op te slaan.

Voorbeelden van cachebeleid

Hier volgen enkele basisvoorbeelden van cachebeleid in API Management. Zie de naslagartikelen voor cachebeleid voor meer voorbeelden.

Cache van reacties

Sla het volledige API-antwoord op in de interne cache om identieke aanvragen te bedienen zonder back-end verbindingen. In dit voorbeeld worden reacties in de cache zeven dagen opgeslagen.

<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>version</vary-by-query-parameter>
        </cache-lookup>
    </inbound>
    <outbound>
        <cache-store duration="604800" />
        <base />
    </outbound>
</policies>

Waarde-caching

Sla specifieke gegevenswaarden op voor hergebruik in meerdere aanvragen.

<policies>
    <inbound>
        <cache-lookup-value key="user-preferences" default-value="none" variable-name="preferences" />
        <choose>
            <when condition="@(context.Variables["preferences"].ToString() == "none")">
                <!-- Load preferences from backend -->
                <send-request mode="new" response-variable-name="prefsResponse">
                    <set-url>https://backend.api/user/preferences</set-url>
                </send-request>
                <cache-store-value key="user-preferences" value="@(((IResponse)context.Variables["prefsResponse"]).Body.As<string>())" duration="1800" />
            </when>
        </choose>
    </inbound>
</policies>

Snelheidsbeperkingsbeveiliging

Combineer cachezoekacties als best practice met snelheidsbeperking om back-endservices te beveiligen.

<policies>
    <inbound>
        <cache-lookup-value key="@("data-" + context.Request.IpAddress)" variable-name="cachedData" />
        <choose>
            <when condition="@(!context.Variables.ContainsKey("cachedData"))">
                <rate-limit calls="10" renewal-period="60" />
                <!-- Proceed to backend -->
            </when>
            <otherwise>
                <!-- Return cached data without rate limiting -->
                <return-response>
                    <set-body>@((string)context.Variables["cachedData"])</set-body>
                </return-response>
            </otherwise>
        </choose>
    </inbound>
</policies>

Beveiligingsoverwegingen

• Gevoelige gegevens: voorkomen dat reacties in de cache worden opgeslagen die gevoelige of persoonlijke gegevens bevatten
• Cachesleutels: zorg ervoor dat cachesleutels gevoelige informatie niet beschikbaar maken in logboeken of diagnostische gegevens
• Toegangsbeheer: voor externe cache zijn de juiste netwerkbeveiligings- en toegangsbeheer vereist
• Versleuteling: TLS/SSL gebruiken voor verbindingen met externe cache-exemplaren

Verwante inhoud

• Meer informatie over cachebeleid in API Management
• Externe caching instellen met Azure Managed Redis
• Voorbeelden van aangepaste caching met geavanceerde scenario's
• API Management-prestaties en cachemetriek monitoren