Use a tabela de comparação abaixo para ajudar a decidir qual política usar para seu caso de uso de limitação de taxa:
Cota
SpikeArrest
Use-o para:
Limitar o número de chamadas de proxy de API que um app ou desenvolvedor pode fazer durante um
período específico. A política SpikeArrest é mais adequada para a limitação de taxa em intervalos de tempo mais curtos, como segundos ou minutos. Considere a cota se a contagem precisa for necessária.
Limite o número de chamadas de API que podem ser feitas em um proxy de API em todos os consumidores durante um período específico (normalmente curto). A política de cotas é mais adequada para definir limites em intervalos de tempo mais longos, como dias, semanas, meses ou anos.
Não use para:
Não o utilize para proteger o back-end de destino do seu proxy de API contra picos de tráfego.
Para isso, use a política SpikeArrest.
Não o utilize para contar e limitar o número de conexões que os apps podem fazer ao back-end
de destino do proxy da API durante um período específico. Observação: para todos os casos de uso que exigem contagem precisa, use a política de cotas.
Armazena uma contagem?
Sim
Não
Práticas recomendadas para anexar a política:
Anexe-a ao ProxyEndpoint Request PreFlow, geralmente após a
autenticação do usuário.
Assim, a política pode verificar o contador de cotas no ponto de entrada do proxy
da API.
Anexe-a ao PreEndpointRequest Request PreFlow, geralmente no
início do fluxo.
Isso fornece proteção contra picos no ponto de entrada do proxy da API.
Código de status HTTP quando o limite é atingido:
429 Serviço indisponível
429 Serviço indisponível
É bom saber:
O contador de cotas é armazenado no Cassandra.
Configure a política para sincronizar o contador de maneira assíncrona para poupar
recursos.
A sincronização de contagem assíncrona pode causar um atraso na resposta de limitação
de taxa, o que pode permitir que as chamadas excedam levemente o limite definido.
Permite que você escolha entre um algoritmo de suavização ou um algoritmo de contagem efetivo. O
anterior suaviza o número de solicitações que podem ocorrer em um período especificado, e o
segundo limita o número total de solicitações que podem ocorrer em um período especificado, independentemente
da rapidez com que são enviadas em sequência. Além disso, a suavização não é coordenada entre os processadores de mensagens.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-19 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."]]
