Avant de discuter de celle qui est la meilleure, examinons la différence entre ces commandes. Les deux DEL et UNLINK libérer la partie clé en mode blocage. Et la différence est la façon dont ils libèrent la partie valeur.
DEL libère toujours la partie valeur en mode bloquant. Cependant, si la valeur est trop grande, par ex. trop d'allocations pour une grande LIST ou HASH , il bloque Redis pendant longtemps. Afin de résoudre le problème, Redis implémente le UNLINK commande, c'est-à-dire une suppression "non bloquante".
En fait, UNLINK n'est PAS toujours non bloquant/asynchrone . Si la valeur est petite, par ex. la taille de LIST ou HASH est inférieur à 64 , la valeur sera libérée immédiatement. De cette façon, UNLINK est presque identique à DEL , sauf que cela coûte quelques appels de fonction de plus que DEL . Cependant, si la valeur est grande, Redis place la valeur dans une liste et la valeur sera libérée par un autre thread, c'est-à-dire le non bloquant free. De cette façon, le thread principal doit faire une certaine synchronisation avec le thread d'arrière-plan, et c'est aussi un coût.
En conclusion, si la valeur est petite, DEL est au moins aussi bon que UNLINK . Si la valeur est très grande, par ex. LIST avec des milliers ou des millions d'articles, UNLINK est bien meilleur que DEL . Vous pouvez toujours remplacer en toute sécurité DEL avec UNLINK . Cependant, si vous trouvez que la synchronisation des threads devient un problème (le multi-threading est toujours un casse-tête), vous pouvez revenir à DEL .
MISE À JOUR :
Depuis Redis 6.0, il y a une nouvelle configuration :lazyfree-lazy-user-del . Vous pouvez le définir sur oui , et Redis exécutera le DEL commande comme si vous exécutiez un UNLINK commande.
