Bevor wir diskutieren, welches besser ist, werfen wir einen Blick auf den Unterschied zwischen diesen Befehlen. Beide DEL
und UNLINK
Geben Sie den Schlüsselteil im Blockiermodus frei. Und der Unterschied ist die Art und Weise, wie sie den Wertteil freigeben.
DEL
gibt den Wertteil im Blockiermodus immer frei. Wenn der Wert jedoch zu groß ist, z. zu viele Zuordnungen für eine große LIST
oder HASH
, es blockiert Redis für eine lange Zeit. Um das Problem zu lösen, implementiert Redis den UNLINK
Befehl, d.h. ein 'nicht blockierendes' Löschen.
Genau genommen UNLINK
ist NICHT immer nicht blockierend/asynchron . Wenn der Wert klein ist, z. die Größe von LIST
oder HASH
ist kleiner als 64
, wird der Wert sofort freigegeben. Auf diese Weise UNLINK
ist fast dasselbe wie DEL
, außer dass es ein paar Funktionsaufrufe mehr kostet als DEL
. Wenn der Wert jedoch groß ist, fügt Redis den Wert in eine Liste ein, und der Wert wird von einem anderen Thread freigegeben, d. h. dem nicht blockierenden freien. Auf diese Weise muss der Haupt-Thread etwas mit dem Hintergrund-Thread synchronisieren, und das ist auch mit Kosten verbunden.
Zum Schluss, wenn der Wert klein ist, DEL
ist mindestens so gut wie UNLINK
. Wenn der Wert sehr groß ist, z. LIST
mit Tausenden oder Millionen von Artikeln, UNLINK
ist viel besser als DEL
. Sie können DEL
jederzeit sicher ersetzen mit UNLINK
. Wenn Sie jedoch feststellen, dass die Thread-Synchronisierung zu einem Problem wird (Multi-Threading bereitet immer Kopfschmerzen), können Sie auf DEL
zurücksetzen .
AKTUALISIERUNG:
Seit Redis 6.0 gibt es eine neue Konfiguration:lazyfree-lazy-user-del . Sie können es auf Ja setzen , und Redis führt den DEL
aus Befehl, als würde ein UNLINK
ausgeführt Befehl.