Laten we, voordat we bespreken welke beter is, eens kijken naar het verschil tussen deze commando's. Beide DEL en UNLINK bevrijd het belangrijkste onderdeel in de blokkeermodus. En het verschil is de manier waarop ze het waardegedeelte vrijmaken.
DEL maakt altijd het waardegedeelte vrij in de blokkeermodus. Als de waarde echter te groot is, b.v. te veel toewijzingen voor een grote LIST of HASH , het blokkeert Redis voor een lange tijd. Om het probleem op te lossen, implementeert Redis de UNLINK commando, d.w.z. een 'niet-blokkerende' verwijdering.
In feite, UNLINK is NIET altijd niet-blokkerend/async . Als de waarde klein is, b.v. de grootte van LIST of HASH is kleiner dan 64 , wordt de waarde onmiddellijk vrijgegeven. Op deze manier UNLINK is bijna hetzelfde als DEL , behalve dat het een paar functieaanroepen meer kost dan DEL . Als de waarde echter groot is, plaatst Redis de waarde in een lijst en wordt de waarde vrijgegeven door een andere thread, d.w.z. de niet-blokkerende gratis. Op deze manier moet de hoofdthread enige synchronisatie doen met de achtergrondthread, en dat is ook een kostenpost.
In een conclusie, als de waarde klein is, DEL is minstens zo goed als UNLINK . Als de waarde erg groot is, b.v. LIST met duizenden of miljoenen items, UNLINK is veel beter dan DEL . U kunt DEL altijd veilig vervangen met UNLINK . Als u echter merkt dat de threadsynchronisatie een probleem wordt (multi-threading is altijd lastig), kunt u teruggaan naar DEL .
UPDATE:
Sinds Redis 6.0 is er een nieuwe configuratie:lazyfree-lazy-user-del . U kunt dit instellen op ja , en Redis zal de DEL . uitvoeren commando alsof het uitvoeren van een UNLINK commando.