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-03-12 UTC."],[[["This content focuses on the Quota and SpikeArrest policies within Apigee and Apigee hybrid, which are used to manage request thresholds."],["The 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."],["SpikeArrest 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."],["Both the Quota and SpikeArrest policies trigger a `429` (Service Unavailable) HTTP status code when request limits are reached, indicating a temporary denial of service."],["Shared flows and chaining proxies can be utilized to protect slower backends without impacting API performance."]]],[]]
