Comparación de las políticas de cuota y SpikeArrest

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

Consulta la documentación de Apigee Edge.

Nota: Las políticas Quota y SpikeArrest contabilizan las solicitudes y toman medidas si se supera un umbral de solicitudes específico. Sin embargo, ten en cuenta que los mecanismos por los que estas políticas contabilizan las solicitudes no son los mismos.

Aunque SpikeArrest mantiene los recuentos con una alta fiabilidad, se ha diseñado para usar una caché de Redis con el mejor esfuerzo posible para almacenar sus recuentos. Como la caché no se replica, en algunos casos se pueden perder recuentos, como cuando se reinician los servidores de caché o en otros casos excepcionales.

Por estos motivos, no recomendamos usar SpikeArrest en casos prácticos que requieran un recuento preciso. Solo la política de cuota síncrona ofrece un recuento preciso en todas las regiones en un periodo determinado.

Consulta la tabla comparativa que aparece a continuación para decidir qué política debes usar en tu caso práctico de limitación de frecuencia:

	Cuota	SpikeArrest
Úselo para:	Limita el número de llamadas a proxies de API que puede hacer una aplicación o un desarrollador durante un periodo específico. La política SpikeArrest es más adecuada para limitar la frecuencia en intervalos de tiempo más cortos, como segundos o minutos. Usa Cuota si necesitas que el recuento sea preciso.	Limita el número de llamadas a la API que se pueden hacer en un proxy de API en todos los consumidores durante un periodo específico (normalmente corto). La política de cuota 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 de tu proxy de API frente a picos de tráfico. Para ello, usa la política SpikeArrest.	No la uses para contar y limitar el número de conexiones que las aplicaciones pueden establecer con el backend de destino de tu proxy de API durante un periodo específico. Nota: En los casos prácticos que requieran un recuento preciso, usa la política de cuota.
¿Almacena un recuento?	Sí	No
Prácticas recomendadas para adjuntar la política:	Adjúntalo al PreFlow de la solicitud ProxyEndpoint, normalmente después de la autenticación del usuario. De esta forma, la política puede comprobar el contador de cuota en el punto de entrada de tu proxy de API.	Adjúntala al PreFlow de solicitud de ProxyEndpoint, normalmente al principio del flujo. De esta forma, se proporciona protección contra picos en el punto de entrada de tu proxy de API.
Código de estado HTTP cuando se ha alcanzado el límite:	429 (servicio no disponible)	429 (servicio no disponible)
Información útil:	El contador de cuota se almacena en Cassandra. Configura la política para sincronizar el contador de forma asíncrona y ahorrar recursos. La sincronización asíncrona de contadores puede provocar un retraso en la respuesta de limitación de la frecuencia, lo que puede permitir que se realicen llamadas que superen ligeramente el límite que hayas definido.	Te permite elegir entre un algoritmo de "suavizado" o un algoritmo de recuento efectivo. La primera suaviza el número de solicitudes que se pueden producir en un periodo de tiempo especificado, mientras que la segunda limita el número total de solicitudes que se pueden producir en un periodo de tiempo especificado, independientemente de la rapidez con la que se envíen sucesivamente. Además, el suavizado no se coordina entre los procesadores de mensajes.
Para obtener más detalles, haz lo siguiente:	Política de cuotas	Política de SpikeArrest

Nota: También puedes usar lo siguiente para proteger los back-ends lentos sin que afecte al rendimiento de las APIs:

• Crear flujos compartidos reutilizables: combina políticas y recursos en un flujo compartido que puedes usar en varios proxies de API e incluso en otros flujos compartidos.
• Crear cadenas entre proxies de APIs: especifica que un proxy es el endpoint de destino de otro, lo que conecta los dos proxies en una cadena de proxies. Encadenar proxies de esta forma puede ayudarte a evitar un salto de red y, por lo tanto, a mejorar el rendimiento general.