Utilizza il grafico di confronto riportato di seguito per decidere quale policy utilizzare per
il tuo caso d'uso dilimitazione di frequenzaa:
Quota
SpikeArrest
Utilizzalo per:
Limita il numero di chiamate proxy API che un'app per sviluppatori o uno sviluppatore può effettuare in un
periodo di tempo specifico. La norma SpikeArrest è più adatta per limitazione di frequenza in intervalli di tempo più brevi, come secondi o minuti. Prendi in considerazione la quota se il conteggio accurato è un requisito.
Limita il numero di chiamate API che possono essere effettuate a un proxy API in tutti i consumer
in un periodo di tempo specifico (in genere breve). Il criterio Quota è più adatto per impostare limiti su intervalli di tempo più lunghi, come giorni, settimane, mesi o anni.
Non utilizzarlo per:
Non utilizzarlo per proteggere il backend di destinazione del proxy API dai picchi di traffico.
Per farlo, utilizza il criterio SpikeArrest.
Non utilizzarlo per conteggiare e limitare il numero di connessioni che le app possono effettuare al backend di destinazione del proxy API in un periodo di tempo specifico. Nota: per tutti i casi d'uso che richiedono
un conteggio accurato, utilizza le norme relative alle quote.
Memorizza un conteggio?
Sì
No
Best practice per allegare le norme:
Allegalo al ProxyEndpoint Request PreFlow, in genere dopo l'autenticazione dell'utente.
In questo modo, la policy può controllare il contatore della quota nel punto di ingresso del proxy API.
Collegalo al pre-flusso della richiesta ProxyEndpoint, in genere all'inizio del flusso.
In questo modo, viene fornita una protezione dai picchi nel punto di ingresso del proxy API.
Codice di stato HTTP quando è stato raggiunto il limite:
429 (Servizio non disponibile)
429 (Servizio non disponibile)
Buono a sapersi:
Il contatore della quota è memorizzato in Cassandra.
Configura il criterio per sincronizzare il contatore in modo asincrono per risparmiare
risorse.
La sincronizzazione asincrona dei contatori può causare un ritardo nella risposta
dellimitazione di frequenzaa, che potrebbe consentire chiamate leggermente superiori al limite impostato.
Consente di scegliere tra un algoritmo di "smoothing" o un algoritmo di conteggio effettivo. Il
primo attenua il numero di richieste che possono verificarsi in un periodo di tempo specificato, mentre il secondo
limita il numero totale di richieste che possono verificarsi in un periodo di tempo specificato, indipendentemente
dalla rapidità con cui vengono inviate in successione. Inoltre, lo smoothing non è coordinato tra i processori di messaggi.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-05 UTC."],[[["\u003cp\u003eThis content focuses on the Quota and SpikeArrest policies within Apigee and Apigee hybrid, which are used to manage request thresholds.\u003c/p\u003e\n"],["\u003cp\u003eThe Quota policy is recommended for use cases requiring precise request counting over longer durations like days, weeks, months, or years, offering accurate counting across all regions.\u003c/p\u003e\n"],["\u003cp\u003eSpikeArrest is better suited for rate limiting over short intervals, such as seconds or minutes, and for protecting backend services from sudden traffic spikes, but its request counting may not be entirely accurate due to its use of a Redis cache.\u003c/p\u003e\n"],["\u003cp\u003eBoth the Quota and SpikeArrest policies trigger a \u003ccode\u003e429\u003c/code\u003e (Service Unavailable) HTTP status code when request limits are reached, indicating a temporary denial of service.\u003c/p\u003e\n"],["\u003cp\u003eShared flows and chaining proxies can be utilized to protect slower backends without impacting API performance.\u003c/p\u003e\n"]]],[],null,["# Comparing Quota and SpikeArrest policies\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n| **Key Point:** The [Quota](/apigee/docs/api-platform/reference/policies/quota-policy) and [SpikeArrest](/apigee/docs/api-platform/reference/policies/spike-arrest-policy) policies both count requests and take action if a specified request threshold is exceeded. Be aware, however, that the mechanisms by which these policies count requests are not the same.\n|\n|\n| While SpikeArrest maintains counts with high reliability, it is designed to use a\n| [Redis\n| best-effort cache](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_protocols/redis) to store its counts. Because the cache is not replicated, there are cases where counts may be\n| lost, such as a restart of the cache servers, or other rare cases.\n|\n| For these reasons, we recommend\n| against using SpikeArrest for use cases that require accurate counting. Only the synchronous\n| Quota policy offers accurate counting across all regions in a given timeframe.\n\nUse the comparison chart below to help you decide which policy to use to\nfor your rate limiting use case:\n\n| **Tip:** You can also use the following to protect slow/sluggish backends without impacting the performance of the APIs:\n|\n| - [Creating reusable shared flows:](/apigee/docs/api-platform/fundamentals/shared-flows) Combine policies and resources into a shared flow that you can consume from multiple API proxies, and even from other shared flows.\n| - [Chaining API proxies together](/apigee/docs/api-platform/fundamentals/connecting-proxies-other-proxies): Specify that one proxy is the target endpoint of another, effectively connecting the two proxies in a proxy chain. Chaining proxies in this way can help you avoid a network hop, and so improve overall performance."]]
