Confronto tra i criteri di quota e SpikeArrest

Questa pagina si applica a Apigee e Apigee ibrido.

Visualizza la documentazione di Apigee Edge.

Punto chiave : i criteri di quota e SpikeArrest conteggiano le richieste e intervengono se viene superata una soglia di richieste specificata. Tieni presente, tuttavia, che i meccanismi in base ai quali questi criteri conteggiano le richieste non sono gli stessi.

Sebbene SpikeArrest mantenga i conteggi con un'elevata affidabilità, è progettato per utilizzare una cache secondo il criterio Redis per archiviare i propri conteggi. Poiché la cache non viene replicata, in alcuni casi i conteggi potrebbero andare persi, ad esempio un riavvio dei server cache o altri rari casi.

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

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

	Quota	SpikeArrest
Utilizzalo per:	Limita il numero di chiamate proxy API che uno sviluppatore o un'app può effettuare in un periodo di tempo specifico. Il criterio SpikeArrest è più adatto per limitazione di frequenza su intervalli di tempo più brevi, come secondi o minuti. Considera la quota se è necessario un conteggio preciso.	Limita il numero di chiamate API che è possibile effettuare su un proxy API tra tutti i consumer in un periodo di tempo specifico (in genere breve). Il criterio per le quote è 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 da picchi di traffico. In questo caso, 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 preciso, utilizza i criteri per le quote.
Memorizza un conteggio?	Sì	No
Best practice per allegare le norme:	Collegalo a ProxyEndpoint Request PreFlow, in genere dopo l'autenticazione dell'utente. Questo criterio consente di controllare il contatore delle quote al punto di ingresso del proxy API.	Collegalo a ProxyEndpoint Request PreFlow, in genere all'inizio del flusso. Questa fornisce 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 delle quote è archiviato in Cassandra. Configura il criterio per sincronizzare il contatore in modo asincrono al fine di salvare le risorse. La sincronizzazione del contatore asincrono può causare un ritardo nella risposta con limitazione di frequenza, che potrebbe consentire chiamate leggermente superiori al limite che hai impostato.	Consente di scegliere tra un algoritmo di "smoothing" o un algoritmo di conteggio effettivo. La prima semplifica il numero di richieste che possono verificarsi in un periodo di tempo specificato e la seconda limita il numero totale di richieste che possono verificarsi in un periodo di tempo specificato, indipendentemente dalla velocità con cui vengono inviate in successione. Inoltre, il perfezionamento non è coordinato tra i processori di messaggi.
Ulteriori dettagli:	Criteri per le quote	Criterio di SpikeArrest

Suggerimento: puoi anche utilizzare le seguenti opzioni per proteggere i backend lenti/lenti 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 anche da altri flussi condivisi.
• Concatenamento tra proxy API: specifica che un proxy è l'endpoint di destinazione di un altro, connettendo in modo efficace i due proxy in una catena di proxy. concatenare i proxy in questo modo può aiutarti a evitare un hop di rete e quindi a migliorare le prestazioni complessive.