Confronto tra i criteri Quota e SpikeArrest

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Punto chiave: i criteri Quota e SpikeArrest conteggiano le richieste e intervengono se viene superata una soglia di richieste specificata. Tieni presente, tuttavia, che i meccanismi con cui queste norme conteggiano le richieste non sono gli stessi.

Sebbene SpikeArrest mantenga i conteggi con elevata affidabilità, è progettato per utilizzare una cache Redis con il criterio del "best effort" per memorizzare i conteggi. Poiché la cache non viene replicata, in alcuni casi i conteggi potrebbero essere persi, ad esempio in caso di riavvio dei server cache o in altri casi rari.

Per questi motivi, sconsigliamo di utilizzare SpikeArrest per i casi d'uso che richiedono un conteggio preciso. Solo il criterio di quota sincrono offre un conteggio preciso in tutte le regioni in un determinato periodo di tempo.

Utilizza il grafico di confronto riportato di seguito per decidere quale criterio utilizzare per il tuo caso d'uso di limitazione della frequenza:

	Quota	SpikeArrest
Utilizzalo per:	Limita il numero di chiamate proxy API che uno sviluppatore o un'app per sviluppatori può effettuare in un determinato periodo di tempo. Il criterio SpikeArrest è più adatto per la limitazione della frequenza su intervalli di tempo più brevi, come secondi o minuti. Valuta la possibilità di utilizzare Quota se il conteggio accurato è un requisito.	Limita il numero di chiamate API che possono essere effettuate su un proxy API per tutti i consumatori in un periodo di tempo specifico (in genere breve). Il criterio di quota è più adatto per impostare limiti su intervalli di tempo più lunghi come giorni, settimane, mesi o anni.
Non utilizzarlo per:	Non utilizzarlo per proteggere il backend di destinazione del proxy API dagli picchi di traffico. A tale scopo, utilizza il criterio SpikeArrest.	Non utilizzarlo per conteggiare e limitare il numero di connessioni che le app possono effettuare al backend di destinazione del proxy API in un determinato periodo di tempo. Nota: per tutti i casi d'uso che richiedono un conteggio accurato, utilizza il criterio di quota.
Memorizza un conteggio?	Sì	No
Best practice per l'attacco del criterio:	Allegalo al PreFlow della richiesta ProxyEndpoint, in genere dopo l'autenticazione dell'utente. In questo modo, il criterio può controllare il contatore delle quote nel punto di contatto del proxy API.	Collegalo al PreFlow della richiesta ProxyEndpoint, in genere all'inizio del flusso. In questo modo viene fornita una protezione contro i picchi nel punto di contatto del proxy API.
Codice di stato HTTP quando viene raggiunto il limite:	429 (servizio non disponibile)	429 (servizio non disponibile)
Buono a sapersi:	Il contatore della quota è archiviato in Cassandra. Configura il criterio per sincronizzare il contatore in modo asincrono per risparmiare risorse. La sincronizzazione asincrona del contatore può causare un ritardo nella risposta del limite di frequenza, il che potrebbe consentire chiamate leggermente superiori al limite impostato.	Ti consente di scegliere tra un algoritmo di "appiattimento" o un algoritmo di conteggio effettivo. Il primo uniforma il numero di richieste che possono verificarsi in un determinato periodo di tempo, mentre il secondo limita il numero totale di richieste che possono verificarsi in un determinato periodo di tempo, indipendentemente dalla velocità con cui vengono inviate in successione. Inoltre, l'appiattimento non è coordinato tra i diversi processori di messaggi.
Per ulteriori dettagli:	Criteri per le quote	Criterio SpikeArrest

Suggerimento: puoi anche utilizzare quanto segue per proteggere i backend lenti/rallentati senza influire sulle prestazioni delle API:

• Creazione di flussi condivisi riutilizzabili: combina criteri e risorse in un flusso condiviso che puoi utilizzare da più proxy API e persino da altri flussi condivisi.
• Concatenamento di proxy API: specifica che un proxy è l'endpoint di destinazione di un altro, collegando efficacemente i due proxy in una catena di proxy. Collegare i proxy in questo modo può aiutarti a evitare un hop di rete e quindi a migliorare il rendimento complessivo.