Edit:Nu med den opdaterede kode tror jeg, at din metode er fundamentalt mangelfuld bortset fra det, du rapporterer.
Den måde du har implementeret det på, skal du køre KEYS i produktion - det er dårligt. Når du skalerer ud, vil du forårsage en voksende og unødvendig systemblokerende belastning på serveren. Som hver eneste del af dokumentationen på den siger, ikke brug keys i produktion. Bemærk, at indkodning af udløbstiden i nøglenavnet ikke giver dig nogen fordel. Hvis du lavede den del af nøglenavnet til oprettelsestidsstemplet, eller endda et tilfældigt tal, ville intet ændre sig. Faktisk, hvis du fjernede den bit, ville intet ændre sig.
En mere fornuftig rute ville i stedet være at bruge et nøglenavn, som ikke er tidsafhængigt. Brugen af udløb håndterer den funktion for dig. Lad os kalde din takstbegrænsede ting for en "session". Dit nøglenavn uden tidsstemplet er "sessions-id'et". Ved at indstille et udløb på 60'erne på det, vil det ikke længere være tilgængeligt ved 61'er-mærket. Så du kan sikkert øge og sammenligne resultatet til din grænse uden at skulle kende det aktuelle tidspunkt eller udløbstid. Alt du behøver er et statisk nøglenavn og et passende udløbsdato.
Hvis du INCR en ikke-eksisterende nøgle, vil Redis returnere "1", hvilket betyder, at den oprettede nøglen og øgede den i et enkelt trin/opkald. så grundlæggende lyder logikken sådan her:
- opret "session"-id
- stigningstæller ved hjælp af ID
- sammenlign resultat med grænse
- hvis antal ==1, skal du indstille udløbet til 60s
- id count> grænse, afvis
Trin 3.1 er vigtigt. Et antal på 1 betyder, at dette er en ny nøgle i Redis, og du vil indstille dit udløb på den. Alt andet betyder, at udløbet allerede burde være indstillet. Hvis du indstiller det i 3.2, vil du bryde processen, fordi det vil bevare tælleren i mere end 60'er.
Med dette behøver du ikke at have dynamiske nøglenavne baseret på udløbstid, og behøver derfor ikke bruge keys for at finde ud af, om der er en eksisterende "session" for det satsbegrænsede objekt. Det gør også din kode meget mere enkel og forudsigelig, samt reducerer rundrejser til Redis - hvilket betyder, at den vil belaste Redis lavere og yde bedre. Hvordan man gør det med det klientbibliotek, du bruger, kan jeg ikke sige, fordi jeg ikke er så bekendt med det. Men den grundlæggende sekvens burde kunne oversættes til den, da den er ret grundlæggende og enkel.
Hvad du imidlertid ikke har vist, er noget, der understøtter påstanden om, at udløbet ikke sker. Det eneste, du har gjort, er at vise, at Redis faktisk bliver bedt om det og indstiller en udløbsdato. For at understøtte din påstand skal du vise, at nøglen ikke udløber. Hvilket betyder, at du skal vise hentning af nøglen efter udløbstiden, og at tælleren ikke blev "nulstillet" ved at blive genskabt efter udløbet. En måde, hvorpå du kan se, at udløbet sker, er at bruge notifikationer om tasterum. Med det vil du kunne se Redis sige, at en nøgle var udløbet.
Hvor denne proces vil mislykkes en smule, er hvis du laver flere vinduer til hastighedsbegrænsning, eller hvis du har et meget større vindue (dvs. 10 minutter), i hvilket tilfælde sorterede sæt kan være en mere fornuftig mulighed for at forhindre front-loading af anmodninger - hvis ønsket. Men som dit eksempel er skrevet, vil ovenstående fungere fint.