Comparar políticas de cuota y SpikeArrest

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

Punto clave: Las políticas de cuotas y SpikeArrest cuentan las solicitudes y toman medidas si se excede un umbral de solicitudes especificado. Sin embargo, ten en cuenta que los mecanismos mediante los cuales estas políticas cuentan solicitudes no son los mismos.

Si bien SpikeArrest mantiene los recuentos con alta confiabilidad, está diseñado para usar una caché de mejor esfuerzo de Redis a fin de almacenar sus recuentos. Debido a que la caché no se replica, hay casos en los que los conteos pueden perderse, como un reinicio de los servidores de caché o, también, otros casos excepcionales.

Por estas razones, recomendamos no usar SpikeArrest para casos de uso que requieren un recuento preciso. Solo la política síncrona de cuotas ofrece recuentos precisos en todas las regiones durante un período determinado.

Usa el siguiente cuadro de comparación a fin de decidir qué política usar para tu caso de uso de límite de frecuencia:

	Cuota	SpikeArrest
Puedes usarlo para lo siguiente:	Limita la cantidad de llamadas al proxy de API que una app o desarrollador puede realizar durante un período específico. La política de SpikeArrest es más adecuada para el límite de frecuencia en intervalos de tiempo más cortos, como segundos o minutos. Considera la política de cuotas si el recuento preciso es un requisito.	Limita la cantidad de llamadas a la API que se pueden realizar en un proxy de API en todos los consumidores durante un período específico (por lo general, corto). La política de cuotas es más adecuada para establecer límites en intervalos de tiempo más largos, como días, semanas, meses o años.
No lo uses para lo siguiente:	No la uses para proteger el backend de destino del proxy de API contra los aumentos de tráfico. Para eso, usa la política SpikeArrest.	No lo uses para contar y limitar la cantidad de conexiones que las apps pueden realizar en el backend de destino del proxy de API durante un período específico. Nota: Para cualquier caso de uso que requiera un recuento preciso, usa la política de cuotas.
¿Almacena un recuento?	Sí	No
Prácticas recomendadas para adjuntar la política:	Adjúntala al flujo previo de solicitudes de ProxyEndpoint, por lo general, después de la autenticación del usuario. Esto permite que la política verifique el contador de cuotas en el punto de entrada del proxy de API.	Adjúntala al flujo previo de solicitudes de ProxyEndpoint, por lo general, al principio del flujo. Esto proporciona protección contra los aumentos de tráfico en el punto de entrada del proxy de API.
Código de estado HTTP cuando se alcanza el límite:	429 Servicio no disponible	429 Servicio no disponible
Información útil:	El contador de cuotas se almacena en Cassandra. Configura la política para sincronizar el contador de forma asíncrona con el fin de guardar recursos. La sincronización asíncrona del contador puede causar un retraso en la respuesta del límite de frecuencia, lo que puede permitir que las llamadas superen apenas el límite que estableciste.	Te permite elegir entre un algoritmo de “suavizamiento” o un algoritmo de recuento eficaz. El primero reduce la cantidad de solicitudes que pueden ocurrir en un período especificado y el último limita la cantidad total de solicitudes que pueden ocurrir dentro de un período específico, sin importar qué tan rápido se envíen sucesivamente. Además, el suavizamiento no está coordinado en los Message Processors.
Obtén más detalles:	Política de cuotas	Política de SpikeArrest

Sugerencia: También puedes usar lo siguiente para proteger backends lentos sin afectar el rendimiento de las API:

• Crear flujos compartidos reutilizables: Combina políticas y recursos en un flujo compartido que puedes consumir desde varios proxies de API, e incluso de otros flujos compartidos.
• Encadenar proxies de API: especifica que un proxy es el extremo objetivo de otro y conecta de manera efectiva los dos proxies en una cadena de proxy. La cadena de proxies de esta forma puede ayudarte a evitar un salto de red y, así, mejorar el rendimiento general.