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 best-effort per archiviare i conteggi. Poiché la cache non viene replicata, in alcuni casi i conteggi potrebbero andare persi, ad esempio in caso di riavvio dei server della cache o in altri rari casi.

Per questi motivi, sconsigliamo di utilizzare SpikeArrest per i casi d'uso che richiedono un conteggio accurato. Solo la policy di quota sincrona offre un conteggio accurato in tutte le regioni in un determinato periodo di tempo.

Utilizza il grafico di confronto riportato di seguito per decidere quale policy utilizzare per il tuo caso d'uso dilimitazione di frequenzaa:

	Quota	SpikeArrest
Utilizzalo per:	Limita il numero di chiamate proxy API che un'app per sviluppatori o uno sviluppatore può effettuare in un periodo di tempo specifico. La norma SpikeArrest è più adatta per limitazione di frequenza in intervalli di tempo più brevi, come secondi o minuti. Prendi in considerazione la quota se il conteggio accurato è un requisito.	Limita il numero di chiamate API che possono essere effettuate a un proxy API in tutti i consumer in un periodo di tempo specifico (in genere breve). Il criterio 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 dai picchi di traffico. Per farlo, 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 periodo di tempo specifico. Nota: per tutti i casi d'uso che richiedono un conteggio accurato, utilizza le norme relative alle quote.
Memorizza un conteggio?	Sì	No
Best practice per allegare le norme:	Allegalo al ProxyEndpoint Request PreFlow, in genere dopo l'autenticazione dell'utente. In questo modo, la policy può controllare il contatore della quota nel punto di ingresso del proxy API.	Collegalo al pre-flusso della richiesta ProxyEndpoint, in genere all'inizio del flusso. In questo modo, viene fornita una protezione dai picchi nel punto di ingresso del proxy API.
Codice di stato HTTP quando è stato raggiunto il limite:	429 (Servizio non disponibile)	429 (Servizio non disponibile)
Buono a sapersi:	Il contatore della quota è memorizzato in Cassandra. Configura il criterio per sincronizzare il contatore in modo asincrono per risparmiare risorse. La sincronizzazione asincrona dei contatori può causare un ritardo nella risposta dellimitazione di frequenzaa, che potrebbe consentire chiamate leggermente superiori al limite impostato.	Consente di scegliere tra un algoritmo di "smoothing" o un algoritmo di conteggio effettivo. Il primo attenua il numero di richieste che possono verificarsi in un periodo di tempo specificato, mentre il secondo limita il numero totale di richieste che possono verificarsi in un periodo di tempo specificato, indipendentemente dalla rapidità con cui vengono inviate in successione. Inoltre, lo smoothing non è coordinato tra i processori di messaggi.
Scopri di più:	Criteri per le quote	Norme SpikeArrest

Suggerimento: puoi anche utilizzare quanto segue per proteggere i backend lenti/pigri 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 di fatto i due proxy in una catena di proxy. Il concatenamento dei proxy in questo modo può aiutarti a evitare un hop di rete e quindi a migliorare le prestazioni complessive.