Database Reference
In-Depth Information
existiert, und innerhalb dieser 10 Sekunden wird eine 1 (wahr) zurückgege-
ben. Wenn Sie ein wenig warten, wird schließlich 0 (falsch) zurückgeliefert.
redis 127.0.0.1:6379> SET ice "I'm melting..."
OK
redis 127.0.0.1:6379> EXPIRE ice 10
(integer) 1
redis 127.0.0.1:6379> EXISTS ice
(integer) 1
redis 127.0.0.1:6379> EXISTS ice
(integer) 0
Das Setzen und Verfallenlassen von Schlüsseln ist bei Redis so weit verbrei-
tet, dass es dafür einen eigenen Kurzbefehl namens
SETEX
gibt.
redis 127.0.0.1:6379> SETEX ice 10 "I'm melting..."
Sie können mit
TTL
feststellen, wie lange ein Schlüssel noch zu leben hat.
Wenn Sie die Verfallszeit von
ice
wie oben beschrieben festlegen und dann
seine TTL prüfen, erhalten Sie die noch verbliebene Restzeit in Sekunden
zurück.
redis 127.0.0.1:6379> TTL ice
(integer) 4
Bevor der Schlüssel abläuft, können Sie den Timeout noch zu jeder Zeit mit
PERSIST schlüssel
aufheben.
redis 127.0.0.1:6379> PERSIST ice
Soll ein Schlüssel zu einem bestimmten Zeitpunkt ablaufen, können Sie mit
EXPIREAT
einen *nix-Zeitstempel (Sekunden seit dem 1.1.1970) angeben. Mit
anderenWortenist
EXPIREAT
für absolute Timeouts gedacht, während
EXPIRE
relative Timeouts verwendet.
Ein gängiger Trick, nur aktiv genutzte Schlüssel vorzuhalten, besteht darin,
die Ablaufzeit immer dann zu aktualisieren, wenn ein Wert abgerufen wird.
Das ist der sog. MRU (moste recently used, zu deutsch etwa zuletzt genutzt)-
Caching-Algorithmus, der sicherstellt, dass nur die zuletzt genutzten Schlüs-
sel in Redis verbleiben, während die anderen ganz normal auslaufen.
Namensräume
Bisher haben wir nur mit einem Namensraum gearbeitet. Genau wie bei Ri-
ak-Buckets müssen wir Schlüssel manchmal durch Namensräume trennen.
Wenn Sie zum Beispiel einen internationalisierten Schlüssel/Wert-Speicher
