Quando si consuma una API, qual è un buon modo per gestire i limiti delle loro richieste?

Naviga le tue risposte
2

La mia app sta consumando un'API di terze parti. Uno dei requisiti di questa API è che la mia app non può inviare più di 20 richieste al secondo. A causa della natura di questa app e perché la mia base di utenti è in crescita, stiamo raggiungendo questo limite molto frequentemente.

(Una cosa da notare sulla mia app: consiste in 4 processi in background separati, eseguiti indipendentemente, e ognuno di questi 4 processi ha colpito l'API di terze parti in momenti diversi, in base a un numero di condizioni)

Ho trovato 2 soluzioni possibili per aggirare il limite di velocità, ma entrambe le soluzioni sembrano imperfette:

  1. Implementa una cache globale (possibilmente redis) che tiene traccia di tutte le richieste in uscita verso l'API di terze parti. Ogni volta che ognuno dei miei processi tenta una richiesta, prima controlla la cache. Se ci sono meno di 20 nel secondo passato, quindi procedere. In caso contrario, attendi un tempo specificato e ricontrolla.

  2. Implementa una cache globale, una coda e un quinto processo dedicato alla gestione delle richieste Web per questa API di terze parti. Ognuno dei miei 4 processi inserisce le richieste in coda (invece di inviare direttamente la richiesta). Il quinto processo controlla la coda, controlla le condizioni (< 20 richieste nel secondo passato), effettua la richiesta web e riporta i risultati nella coda (Ognuno gestiva UNO alla volta). Nel frattempo, l'altro processo (che ha inserito la richiesta originale nella coda) esegue il polling della coda per la risposta. E una volta che la risposta è presente, la afferra (e rimuove l'elemento dalla coda) e procede in modo allegro.

Il mio problema con # 1 è la precisione. È concepibile che tutti e 4 i processi controllino la cache simultaneamente, e il conteggio attuale sia 19. Tutti e 4 i processi ottengono il semaforo verde e inviano le loro richieste contemporaneamente, portando il conteggio a 23, e poi la mia app viene bloccata per superare il limite .

Il mio problema con # 2 è la complessità. Ritengo che la precisione reggerà, dal momento che il quinto processo garantisce che tutte le richieste vengano gestite una alla volta, quindi non c'è possibilità di rompere il limite a causa delle condizioni di gara. Tuttavia, sembra solo fragile e probabilmente eccessivo. Sto introducendo molte parti mobili, il che significa (secondo la mia esperienza) che molto potrebbe andare storto, e potrebbe essere difficile rintracciare gli errori.

Esistono altre soluzioni a questo problema? Ci sto pensando troppo? # 1 o # 2 andrebbero bene?

    
posta Matt Spinks 22.07.2018 - 15:42
fonte

2 risposte

2

Se il servizio funziona rifiutando solo le richieste che sono al di sopra del limite e non limitandosi a uccidere l'intero servizio per te, allora potresti implementare un algoritmo simile a quello di TCP.

Detto semplicemente, ogni cliente inizia a inviare richieste il più velocemente possibile. Quando le richieste iniziano a essere rifiutate, rallenterà quanto basta perché le richieste non vengano respinte troppo. Quindi, proverebbe ad aumentare la frequenza a intervalli casuali, verificando se è possibile aumentare la velocità per se stessa.

Ovviamente questo non renderà possibile fare più richieste, ma renderà possibile per ogni cliente avere un morso della torta.

Inoltre, se ti aspetti che clienti diversi abbiano richieste simili, allora una qualche forma di caching globale migliorerà sicuramente la situazione.

    
risposta data 22.07.2018 - 15:54
fonte
1

Sarei anche venuto fuori e ho utilizzato la seconda opzione come indicato, principalmente a causa del fatto che questo approccio significa che il "servizio" di accesso all'API è separato. Questo offre molti vantaggi come avere un singolo punto di cambiamento se \ quando l'interfaccia API cambia, consente di elaborare le informazioni API in un formato più desiderabile prima di passare agli altri processi se lo si desidera, ma anche di iniziare un effettivo meccanismo di memorizzazione nella cache in cima a un attacco più facile come si era accennato in precedenza.

Come ulteriore vantaggio questo ti permetterà di avere un quadro di sorta quando si tratta di altre API e di utilizzare più facilmente l'API in un altro progetto se \ quando ne viene fuori la necessità

    
risposta data 24.07.2018 - 17:24
fonte

Leggi altre domande sui tag

Come gestire l'eliminazione del record con i record associati? Come faccio a distinguere tra elementi appartenenti alla libreria standard, gemme specifiche e quelli generati dall'utente in Ruby?