Comparar políticas de Quota e SpikeArrest

Esta página se aplica à Apigee e à Apigee híbrida.

Confira a documentação da Apigee Edge.

Importante: as políticas de Cota e SpikeArrest contam solicitações e agem se um limite de solicitação especificado for excedido. No entanto, esteja ciente de que os mecanismos pelos quais essas políticas contam solicitações não são os mesmos.

Embora a SpikeArrest mantenha contagens com alta confiabilidade, ele foi projetado para usar um cache de melhor esforço Redis para armazenar suas contagens. Como o cache não é replicado, há casos em que as contagens podem ser perdidas, como uma reinicialização dos servidores desse tipo ou outros casos raros.

Por esses motivos, não recomendamos o uso do SpikeArrest para casos de uso que exijam uma contagem precisa. Somente a política síncrona de cotas oferece contagem precisa em todas as regiões em um determinado período.

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.
Veja mais detalhes:	Política de cotas	Política de Detenção de pico

Dica: você também pode usar o seguinte para proteger back-ends lentos sem afetar o desempenho das APIs:

• Criar fluxos compartilhados reutilizáveis: combine políticas e recursos em um fluxo compartilhado que você pode consumir de vários proxies de API e até mesmo de outros fluxos compartilhados.
• Encadear proxies de API juntos: especifique que um proxy é o endpoint de destino de outro, conectando efetivamente os dois proxies em uma cadeia. Encadear proxies dessa maneira pode ajudar a evitar um salto de rede e, portanto, melhorar o desempenho geral.