Modifica:ora, con il codice aggiornato, credo che la tua metodologia sia fondamentalmente imperfetta a parte ciò che stai segnalando.
Il modo in cui l'hai implementato richiede l'esecuzione di KEYS in produzione - questo è male. Man mano che si aumenta la scalabilità, si verificherà un carico di blocco del sistema crescente e non necessario sul server. Come dice ogni pezzo di documentazione su di esso, non usa i keys in produzione. Si noti che la codifica del tempo di scadenza nel nome della chiave non offre alcun vantaggio. Se hai reso quella parte del nome della chiave un timestamp di creazione, o anche un numero casuale, non cambierebbe nulla. In effetti, se rimuovessi quel bit, non cambierebbe nulla.
Un percorso più sano sarebbe invece quello di utilizzare un nome chiave che non dipenda dal tempo. L'uso della scadenza gestisce che funzionano per te. Chiamiamo la tua cosa a tariffa limitata una "sessione". Il nome della tua chiave senza timestamp è "ID sessione". Impostando una scadenza di 60 secondi su di esso, non sarà più disponibile al segno di 61 secondi. In questo modo puoi aumentare e confrontare in sicurezza il risultato con il tuo limite senza dover conoscere l'ora corrente o il tempo di scadenza. Tutto ciò di cui hai bisogno è un nome di chiave statica e una scadenza appropriata impostata su di essa.
Se INCR una chiave non esistente, Redis restituirà "1" il che significa che ha creato la chiave e l'ha incrementata in un unico passaggio/chiamata. quindi sostanzialmente la logica va così:
- crea ID "sessione"
- incrementa il contatore utilizzando l'ID
- confronta il risultato con il limite
- se conteggio ==1, imposta la scadenza a 60 secondi
- conteggio ID> limite, rifiuto
Il passaggio 3.1 è importante. Un conteggio di 1 significa che questa è una nuova chiave in Redis e vuoi impostare la tua scadenza su di essa. Qualsiasi altra cosa significa che la scadenza dovrebbe essere già stata impostata. Se lo imposti in 3.2 interromperai il processo perché conserverà il contatore per più di 60 secondi.
Con questo non è necessario disporre di nomi di chiavi dinamici basati sul tempo di scadenza, e quindi non è necessario utilizzare keys per scoprire se esiste una "sessione" esistente per l'oggetto a tariffa limitata. Inoltre, rende il tuo codice molto più semplice e prevedibile, oltre a ridurre i round trip a Redis, il che significa che avrà un carico inferiore su Redis e prestazioni migliori. Su come farlo con la libreria client che stai utilizzando non posso dirlo perché non ne ho molta familiarità. Ma la sequenza di base dovrebbe essere traducibile in essa in quanto è abbastanza semplice e di base.
Ciò che non hai mostrato, tuttavia, è qualcosa a sostegno dell'affermazione che la scadenza non sta avvenendo. Tutto quello che hai fatto è mostrare che a Redis è stato effettivamente detto e impostare una scadenza. Per supportare la tua richiesta devi dimostrare che la chiave non ha scadenza. Ciò significa che è necessario mostrare il recupero della chiave dopo il tempo di scadenza e che il contatore non è stato "reimpostato" essendo stato ricreato dopo la scadenza. Un modo per vedere che la scadenza sta avvenendo è utilizzare le notifiche dello spazio chiave. Con ciò sarai in grado di vedere Redis che dice che una chiave è scaduta.
Il punto in cui questo processo fallirà un po' è se si eseguono più finestre per limitare la velocità o se si dispone di una finestra molto più ampia (ad es. 10 minuti), nel qual caso i set ordinati potrebbero essere un'opzione più sana per impedire il caricamento anticipato delle richieste - se desiderato. Ma come è scritto il tuo esempio, quanto sopra funzionerà perfettamente.
