Bearbeiten:Jetzt, mit dem aktualisierten Code, glaube ich, dass Ihre Methodik abgesehen von dem, was Sie melden, grundlegend fehlerhaft ist.
So wie Sie es implementiert haben, müssen Sie KEYS ausführen in der Produktion - das ist schlecht. Beim Aufskalieren verursachen Sie eine wachsende und unnötige systemblockierende Last auf dem Server. Wie jede Dokumentation darauf sagt, tun Sie es nicht Verwenden Sie keys in Produktion. Beachten Sie, dass die Kodierung der Ablaufzeit im Schlüsselnamen keinen Vorteil bringt. Wenn Sie diesen Teil des Schlüsselnamens zum Erstellungszeitstempel oder sogar zu einer Zufallszahl machen, würde sich nichts ändern. In der Tat, wenn Sie dieses Bit entfernen, würde sich nichts ändern.
Eine vernünftigere Route wäre stattdessen die Verwendung eines Schlüsselnamens, der nicht zeitabhängig ist. Die Verwendung des Ablaufs übernimmt diese Funktion für Sie. Nennen wir Ihr ratenbegrenztes Ding eine "Session". Ihr Schlüsselname ohne Zeitstempel ist die "Sitzungs-ID". Indem Sie ein Ablaufdatum von 60 Sekunden festlegen, ist es bei der 61-Sekunden-Marke nicht mehr verfügbar. So können Sie das Ergebnis sicher erhöhen und mit Ihrem Limit vergleichen, ohne die aktuelle Zeit oder Ablaufzeit kennen zu müssen. Alles, was Sie brauchen, ist ein statischer Schlüsselname und ein passendes Ablaufdatum dafür.
Wenn Sie INCR Bei einem nicht vorhandenen Schlüssel gibt Redis "1" zurück, was bedeutet, dass der Schlüssel erstellt und in einem einzigen Schritt/Aufruf erhöht wurde. also im Grunde geht die Logik so:
- "Sitzungs"-ID erstellen
- Zähler mit ID erhöhen
- Ergebnis mit Grenzwert vergleichen
- wenn count ==1, setzen Sie das Ablaufdatum auf 60 Sekunden
- id count> limit, ablehnen
Schritt 3.1 ist wichtig. Eine Zählung von 1 bedeutet, dass dies ein neuer Schlüssel in Redis ist und Sie Ihren Ablauf darauf festlegen möchten. Alles andere bedeutet, dass das Ablaufdatum bereits festgelegt sein sollte. Wenn Sie es in 3.2 einstellen, brechen Sie den Prozess ab, da der Zähler länger als 60 Sekunden erhalten bleibt.
Damit benötigen Sie keine dynamischen Schlüsselnamen basierend auf der Ablaufzeit und müssen daher keine keys verwenden um herauszufinden, ob es eine bestehende "Sitzung" für das ratenbegrenzte Objekt gibt. Es macht Ihren Code auch viel einfacher und vorhersehbarer und reduziert Roundtrips zu Redis – was bedeutet, dass Redis weniger belastet wird und eine bessere Leistung erbringt. Wie man das mit der von Ihnen verwendeten Client-Bibliothek macht, kann ich nicht sagen, weil ich damit nicht so vertraut bin. Aber die grundlegende Sequenz sollte darauf übersetzbar sein, da sie ziemlich einfach und einfach ist.
Was Sie jedoch nicht gezeigt haben, ist irgendetwas, das die Behauptung stützt, dass der Ablauf nicht stattfindet. Alles, was Sie getan haben, ist zu zeigen, dass Redis tatsächlich dazu aufgefordert wird, und ein Ablaufdatum festzulegen. Um Ihren Anspruch zu untermauern, müssen Sie nachweisen, dass der Schlüssel nicht abläuft. Das bedeutet, dass Sie zeigen müssen, dass der Schlüssel nach der Ablaufzeit abgerufen wurde und dass der Zähler nicht "zurückgesetzt" wurde, indem er nach Ablauf neu erstellt wurde. Eine Möglichkeit, den Ablauf zu sehen, ist die Verwendung von Keyspace-Benachrichtigungen. Damit können Sie sehen, dass Redis sagt, dass ein Schlüssel abgelaufen ist.
Wo dieser Prozess ein wenig fehlschlagen wird, wenn Sie mehrere Fenster zur Ratenbegrenzung verwenden oder wenn Sie ein viel größeres Fenster haben (z. B. 10 Minuten), in welchem Fall sortierte Sätze eine vernünftigere Option sein könnten, um das Vorabladen von Anforderungen zu verhindern - wenn gewünscht. Aber wie Ihr Beispiel geschrieben ist, wird das obige gut funktionieren.
