Redis: Feature neuer Befehl GETEX

Sie können einfach GET + EXPIRE in einer Transaktion verwenden.

@badboy Get and touch ist ein gängiges Muster und in Bezug auf die API-Parität verstehe ich nicht, warum SETEX ohne Transaktion ausgeführt wird und GET + EXPIRE eine Transaktion erfordert. Können wir das nachholen? Auch in #1652 gefragt.

Ist das verfügbar?

Dies sollte implementiert werden, und ex ist ein häufiger Anwendungsfall.

@HcgRandon Mir geht es genauso.

@HcgRandon Wie kann ich den Ablauf in einem GET festlegen: https://redis.io/commands/get in einem einzigen Vorgang/Aufruf? Wenn wir das tun könnten, würde es viele zusätzliche Anfragen an den Server ersparen. Das ist der Sinn von SET mit EX-, NX- und XX-Flags.

Derzeit ist kein Befehl dafür implementiert. Sie können MULTI; GET x; EXPIRE x 1000; EXEC oder ein Lua-Skript verwenden, um dasselbe zu tun.

Richtig, die Transaktion behält die Operation als einzelne Einheit bei, verringert jedoch nicht die Anzahl der Operationen (sondern erhöht und erhöht auch die Latenzen). Lua-Skripting ist eine potenzielle Lösung, um neue Operationen hinzuzufügen, aber dies ist nur für meine Umgebung ein hackiger Weg. Hier versuchen wir, ein Argument für ein größeres Benutzerbedürfnis vorzubringen.

Darüber hinaus frage ich mich immer noch, warum es nicht in der Baseline Redis enthalten sein sollte, um eine API-Parität mit SETEX oder SET und EX Flag zu erreichen. Ein weiterer Punkt aus meinem Anwendungsfall ist, dass unsere Benutzer von Dynomite keine Transaktionen verwenden können.

Ja, wir sind uns alle sehr bewusst über Scripting und Multi. Mein Punkt ist, dass 'setex' aktuell existiert, weil "es eine übliche API-Nutzung ist". Setex ist atomar, es ist genau gleichbedeutend mit Running Set gefolgt von Expire. Ich schlage vor, dass wir getex hinzufügen, da dies auch ein sehr häufiger Anwendungsfall von redis ist. Setex existiert ohne Skripting oder Multi. Ich glaube, getex sollte das auch

Erwarten Sie wirklich diese Get-and-Touch-Funktion, und memcached bietet auch diese praktische API.

Manchmal geht eine Stimme in der Mischung verloren. Ich muss hinzufügen, dass ich zustimme, dass dies ein sehr häufiges Anwendungsszenario ist, für das SETEX ein entsprechendes GETEX benötigt, wage ich zu sagen, dass wir mehr Anwendungen für GETEX haben als für SETEX

Ja, die Verwendung von multi/exec reicht aus, aber ich denke nicht, dass dies für diese allgemeine Operation erforderlich sein sollte. Es fühlt sich immer so an, als würde ich etwas falsch machen ... Als würden meine SQL-Wurzeln meinem Redis-Denken im Weg stehen.

Hallo, theoretisch können wir so etwas auf ähnliche Weise modellieren, wie wir es mit SET getan haben, das heißt, indem wir Argumente an GET übergeben. In der Praxis würde dies GET abhängig von den verwendeten Parametern zu einem Schreibbefehl machen, was ein gewisses Problem darstellt ... also im Grunde, wenn wir dieses Muster als Bürger erster Klasse modellieren wollen, müssen wir a hinzufügen GETEX Befehl auf explizite Weise. Ich habe nicht erwartet, dass GETEX ein sehr häufig verwendetes Muster ist, auch wenn ich sehe, wie es unter bestimmten Bedingungen ziemlich nützlich ist, könnten Sie bitte Ihre Anwendungsfälle kommentieren, um ein überzeugendes Argument für die Allgemeingültigkeit vorzubringen Combo-Befehl? Danke.

PS: Beachten Sie auch, dass wir diese Funktion möglicherweise als Option für EXPIRE hinzufügen könnten, auch wenn es sich in gewisser Weise um eine sehr seltsame API handelt ... Ich würde also sagen, dass dies nicht der Fall ist, sondern nur, um alle Optionen auf die Seite zu bringen Tabelle.

Ich habe hier noch keinen Kommentar gesehen, also hoffe ich, dass ich nicht spamme oder im falschen Bereich poste. Wir verwenden es derzeit nur, um die Zeit zu verlängern, in der etwas zwischengespeichert wird, sodass Schlüssel, auf die häufig zugegriffen wird, länger bleiben und Schlüssel, auf die nicht häufig zugegriffen wird, verfallen.

"Können Sie bitte Ihre Anwendungsfälle kommentieren, um ein überzeugendes Argument für die Allgemeingültigkeit dieses Combo-Befehls vorzubringen?"

Manchmal haben verschiedene zwischengespeicherte Elemente eine weite Verteilung in Bezug darauf, wie oft sie angefordert werden, sodass es keinen Sinn macht, einfach dieselbe Ablaufzeit für alle Elemente eines bestimmten Typs zu haben.

Ich mache eine App, die die Twitter-API verwendet. Ich verwende Redis, um die ID von Tweets zwischenzuspeichern, die ich bereits zu MySQL hinzugefügt habe. Um Speicherkapazität zu sparen, möchte ich nicht alle Redis-Elemente auf unbestimmte Zeit beibehalten.

Ich kann für jede zwischengespeicherte Tweet-ID die gleiche Ablaufzeit festlegen (z. B. drei Stunden) und dann – wenn sie in Redis abläuft, aber der beliebte Tweet als Retweet auf einer Benutzerzeitachse angezeigt wird, die meine App liest – meine Datenbank überprüfen erneut, um zu bestätigen, dass der Tweet in MySQL hinzugefügt wurde, und speichern Sie die Tweet-ID erneut für 3 Stunden in Redis.

Aber es wäre besser, wenn die beliebte Tweet-ID nicht von Redis ablaufen würde, denn jedes Mal, wenn ich einen „Get“ darauf mache, verlängere ich die Ablaufzeit um weitere 3 Stunden.

Ich denke, es gibt viele Anwendungsfälle. Angenommen, Sie geben allen Ihren Schlüsseln eine Ablaufzeit. Mit Get und Expire stellen Sie sicher, dass nur die zuletzt verwendeten Schlüssel noch einige Zeit gespeichert werden. Schlüssel, auf die kürzlich nicht zugegriffen wurde, werden aus dem Cache entfernt.

Als jemand, der im Webz surft und hauptsächlich nach Redis-bezogenen Dingen sucht, kann ich definitiv sagen, dass ein RW GETEX mehr als eine übliche Anforderung in den oben genannten Caching-Kontexten ist. Es ist bei weitem der intuitivste Weg, diese beiden Fliegen mit einem einfachen Vorgang zu töten.

Könnten Sie bitte Ihre Anwendungsfälle kommentieren, um ein überzeugendes Argument für die Allgemeingültigkeit dieses Combo-Befehls vorzubringen?

teure Daten im Zusammenhang mit der Benutzersitzung:
Wir haben mehrere App-Server und verwenden Redis, um Benutzerdaten zwischen Servern auszutauschen, während der Benutzer auf unserer Website aktiv ist (zwischen den Seiten navigiert), benötigen wir diese Daten. Wenn der Benutzer die Site verlässt (keine Anfrage mehr), ist es in Ordnung, diese Daten vom Redis-Server zu entfernen.

Gibt es gute Nachrichten für diese Funktionsanfrage? Es wäre sehr hilfreich, einen Ablauf-nach-Zugriff-Cache zu implementieren.

Um die bisherige Diskussion zusammenzufassen:

• Es sieht so aus, als ob GET+EXPIRE häufig genug ist <- lassen Sie uns das bereits lösen.
• Das Ändern GET zur Unterstützung der Ablaufsemantik wird es zu einem Schreibbefehl machen, also eine große Änderung.
• Das Ändern EXPIRE in auch GET wäre eine umständliche API, um es gelinde auszudrücken.

Es sieht also so aus, als bräuchten wir einen neuen String 'Write'-Befehl, der im Wesentlichen aus GET besteht, der mit dem Ablaufwort von SET verschmolzen ist, und möglicherweise den AT -Varianten wie folgt:

GETEX <key>  [KEEPTTL|[PERSIST|EX seconds|PX milliseconds|EXAT seconds-timestamp|PXAT milliseconds-timestamp]]`

Wobei KEEPTTL die TTL nicht berührt und die Standardeinstellung ist. PERSIST entfernt alle TTL.

Die Antwort wäre ein Fehler, eine Massenzeichenfolge oder Null.

Anmerkungen:

• Dies kann als eine Art Ersatz für GETDEL (#6460, #7324) verwendet werden, wenn '0' bis EX/PX oder ein vergangener Zeitstempel für EXAT/PXAT bereitgestellt wird. Oder wenn wir es dazu bringen, eine DEL -Option zu akzeptieren und EX als "erweitert" statt als "ablaufend" zu betrachten: P
• Dies könnte eine weitere mögliche Ergänzung zu 6.2 sein - @redis/core-team?

@itamarhaber eine weitere interessante Idee, die mir eingefallen ist, dass SET XX NX GET EX <ttl> das vielleicht tun könnte (dh wir erlauben sowohl XX als auch NX anzugeben, dass der Schlüssel nicht geändert werden soll).
das ist offensichtlich eine schlechte Idee, aber vielleicht möchten wir die Möglichkeit untersuchen, den Befehl SET mit diesen Funktionen ( DEL und NOSET ) anstelle von GETEX zu erweitern
es wäre immer noch umständlicher als die Verwendung eines GETEX (aber auch ein bisschen umständlich, dass GETEX ein Schreibbefehl ist).

Auf jeden Fall stimme ich zu, dass es auf die eine oder andere Weise eine nette Ergänzung für 6.2 wäre. (obwohl es wirklich keinen Nachteil hat, das mit MULTI-EXEC AFAIK zu tun)

Wenn ich etwas mehr über das Obige nachdenke, mag ich die NOSET- und DEL-Argumente nicht, da dies bedeutet, dass das Wertargument zu groß ist.
Ich tendiere also zu GETEX und GETDEL (oder GETEX mit DEL-Argument, dh was sie gemeinsam haben, ist, dass sie ein Schreibbefehl sind, der den alten Wert zurückgibt und kein neues Wertargument akzeptiert).
wollte nur diese Idee oben auf den Tisch legen.

ps Wenn wir EXAT zu GETEX hinzufügen, sollten wir es natürlich auch zu SET hinzufügen.

Hi @itamarhaber @oranagra Gab es eine Entscheidung, ob dies als GETEX oder als Teil von SET implementiert werden soll? Zur Verdeutlichung: Wir erwarten, dass GETEX wie SETEX ein unabhängiger Befehl ist und würden die Argumente für GET nicht hinzufügen, da dies zu einem Schreibbefehl würde?

@nmvk Ich denke, Itamars letzter Vorschlag ist der richtige.
Ich habe das Kernteam erneut angepingt.
Wir können anfangen, nach jemandem mit etwas Freizeit zu suchen, um dies umzusetzen.

Ich finde GETEX mit einem Löschargument etwas umständlich, aber mir ist nichts Besseres eingefallen. GETEX mit DEL klingt gut genug für mich.

Ich denke, @nmvk möchte es aufgreifen, da er kürzlich einen Beitrag geleistet hat.

Ack @madolson Ich werde mir das ansehen.

AK 👍