Comparar as políticas de Quota e SpikeArrest

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

Ponto-chave: as políticas de Quota e SpikeArrest contabilizam os pedidos e tomam medidas se for excedido um limite de pedidos especificado. No entanto, tenha em atenção que os mecanismos através dos quais estas políticas contabilizam os pedidos não são os mesmos.

Embora o SpikeArrest mantenha as contagens com elevada fiabilidade, foi concebido para usar uma cache de melhor esforço do Redis para armazenar as respetivas contagens. Uma vez que a cache não é replicada, existem casos em que as contagens podem ser perdidas, como um reinício dos servidores de cache ou outros casos raros.

Por estes motivos, recomendamos que não use o SpikeArrest para exemplos de utilização que exijam uma contagem precisa. Apenas a política de quotas síncrona oferece uma contagem precisa em todas as regiões num determinado período.

Use o gráfico de comparação abaixo para ajudar a decidir que política usar para o seu exemplo de utilização de limitação de taxa:

	Quota	SpikeArrest
Use-o para:	Limitar o número de chamadas de proxy de API que uma app de programador ou um programador pode fazer durante um período específico. A política SpikeArrest é mais adequada para limitar a taxa em intervalos de tempo mais curtos, como segundos ou minutos. Considere a quota se a contagem precisa for um requisito.	Limitar o número de chamadas API que podem ser feitas a um proxy de API em todos os consumidores durante um período específico (normalmente curto). A política de quotas é mais adequada para definir limites em intervalos de tempo mais longos, como dias, semanas, meses ou anos.
Não a use para:	Não a use para proteger o back-end de destino do proxy de API contra picos de tráfego. Para tal, use a política SpikeArrest.	Não a use para contabilizar e limitar o número de ligações que as apps podem fazer ao back-end de destino do proxy da API durante um período específico. Nota: para todos os exemplos de utilização que exijam uma contagem precisa, use a política de quotas.
Armazena uma contagem?	Sim	Não
Práticas recomendadas para anexar a política:	Anexe-o ao ProxyEndpoint Request PreFlow, geralmente após a autenticação do utilizador. Isto permite que a política verifique o contador de quotas no ponto de entrada do proxy da API.	Anexe-o ao ProxyEndpoint Request PreFlow, geralmente no início do fluxo. Isto oferece proteção contra picos no ponto de entrada do proxy de API.
Código de estado HTTP quando o limite foi atingido:	429 (Serviço indisponível)	429 (Serviço indisponível)
É bom saber:	O contador de quota é armazenado no Cassandra. Configure a política para sincronizar o contador de forma assíncrona para guardar recursos. A sincronização assíncrona do contador pode causar um atraso na resposta de limitação de taxa, o que pode permitir chamadas ligeiramente superiores ao limite que definiu.	Permite escolher entre um algoritmo de "suavização" ou um algoritmo de contagem eficaz. O primeiro suaviza o número de pedidos que podem ocorrer num período especificado, e o segundo limita o número total de pedidos que podem ocorrer num período especificado, independentemente da rapidez com que são enviados sucessivamente. Além disso, o alisamento não é coordenado entre os processadores de mensagens.
Obtenha mais detalhes:	Política de quotas	Política SpikeArrest

Sugestão: também pode usar o seguinte para proteger os back-ends lentos sem afetar o desempenho das APIs:

• Criar fluxos partilhados reutilizáveis: combine políticas e recursos num fluxo partilhado que pode usar a partir de vários proxies da API e até de outros fluxos partilhados.
• Encadear proxies de API: especifique que um proxy é o ponto final de destino de outro, o que liga efetivamente os dois proxies numa cadeia de proxies. A encadeamento de proxies desta forma pode ajudar a evitar um salto de rede e, assim, melhorar o desempenho geral.