Le tableau comparatif ci-dessous vous aidera à déterminer la règle à utiliser pour votre cas d'utilisation de limitation du débit :
Quota
SpikeArrest
Utilisez-la pour :
Limiter le nombre d'appels de proxy d'API qu'un développeur ou une application peut effectuer sur une période spécifique. La règle SpikeArrest est plus adaptée à la limitation du débit sur des intervalles de temps plus courts (secondes ou minutes par exemple). Envisagez d'utiliser la règle de quota si vous avez besoin d'un décompte précis.
Limiter le nombre d'appels d'API pouvant être effectués sur un même proxy d'API par l'ensemble des clients sur une période spécifique (généralement courte). La règle de quota est plus adaptée pour définir des limites sur des intervalles de temps plus longs (jours, semaines, mois ou années par exemple).
Ne l'utilisez pas pour :
Ne l'utilisez pas pour protéger le backend cible de votre proxy d'API contre les pics de trafic.
Utilisez pour cela la règle SpikeArrest.
Ne l'utilisez pas pour compter et limiter le nombre de connexions que les applications peuvent établir avec le backend cible de votre proxy d'API sur une période donnée. Remarque : Pour tous les cas d'utilisation nécessitant un comptage précis, utilisez la règle de quota.
Stocke un décompte ?
Oui
Non
Bonnes pratiques pour associer la règle :
Associez-la au PreFlow de requête ProxyEndpoint, généralement après l'authentification de l'utilisateur.
Cela permet à la règle de vérifier le compteur de quotas au niveau du point d'entrée du proxy d'API.
Associez-la au PreFlow de requête ProxyEndpoint, généralement au tout début du flux.
Cela offre une protection contre les pics au niveau du point d'entrée du proxy d'API.
Code d'état HTTP une fois la limite atteinte :
429 (Service indisponible)
429 (Service indisponible)
Bon à savoir :
Le compteur de quota est stocké dans Cassandra.
Configurez la règle afin de synchroniser le compteur de manière asynchrone pour enregistrer des ressources.
La synchronisation asynchrone du compteur peut entraîner un retard dans la réponse de limitation du débit, ce qui peut provoquer un nombre d'appels légèrement supérieur à la limite que vous avez définie.
Vous permet de choisir entre un algorithme "à lissage" et un algorithme de comptage efficace. Le premier lisse le nombre de requêtes pouvant survenir au cours d'une période spécifiée et le second limite le nombre total de requêtes pouvant être effectuées au cours d'une période spécifiée, indifféremment de la rapidité à laquelle elles sont envoyées. En outre, le lissage n'est pas coordonné entre les processeurs de messages.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/10 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/10 (UTC)."],[[["\u003cp\u003eThis content focuses on the Quota and SpikeArrest policies within Apigee and Apigee hybrid, which are used to manage request thresholds.\u003c/p\u003e\n"],["\u003cp\u003eThe 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.\u003c/p\u003e\n"],["\u003cp\u003eSpikeArrest 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.\u003c/p\u003e\n"],["\u003cp\u003eBoth the Quota and SpikeArrest policies trigger a \u003ccode\u003e429\u003c/code\u003e (Service Unavailable) HTTP status code when request limits are reached, indicating a temporary denial of service.\u003c/p\u003e\n"],["\u003cp\u003eShared flows and chaining proxies can be utilized to protect slower backends without impacting API performance.\u003c/p\u003e\n"]]],[],null,["# Comparing Quota and SpikeArrest policies\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n| **Key Point:** The [Quota](/apigee/docs/api-platform/reference/policies/quota-policy) and [SpikeArrest](/apigee/docs/api-platform/reference/policies/spike-arrest-policy) policies both count requests and take action if a specified request threshold is exceeded. Be aware, however, that the mechanisms by which these policies count requests are not the same.\n|\n|\n| While SpikeArrest maintains counts with high reliability, it is designed to use a\n| [Redis\n| best-effort cache](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_protocols/redis) to store its counts. Because the cache is not replicated, there are cases where counts may be\n| lost, such as a restart of the cache servers, or other rare cases.\n|\n| For these reasons, we recommend\n| against using SpikeArrest for use cases that require accurate counting. Only the synchronous\n| Quota policy offers accurate counting across all regions in a given timeframe.\n\nUse the comparison chart below to help you decide which policy to use to\nfor your rate limiting use case:\n\n| **Tip:** You can also use the following to protect slow/sluggish backends without impacting the performance of the APIs:\n|\n| - [Creating reusable shared flows:](/apigee/docs/api-platform/fundamentals/shared-flows) Combine policies and resources into a shared flow that you can consume from multiple API proxies, and even from other shared flows.\n| - [Chaining API proxies together](/apigee/docs/api-platform/fundamentals/connecting-proxies-other-proxies): Specify that one proxy is the target endpoint of another, effectively connecting the two proxies in a proxy chain. Chaining proxies in this way can help you avoid a network hop, and so improve overall performance."]]
