Antes de discutir cuál es mejor, echemos un vistazo a la diferencia entre estos comandos. Ambos DEL y UNLINK liberar la parte clave en el modo de bloqueo. Y la diferencia es la forma en que liberan la parte de valor.
DEL siempre libera la parte de valor en modo de bloqueo. Sin embargo, si el valor es demasiado grande, p. demasiadas asignaciones para una LIST grande o HASH , bloquea Redis durante mucho tiempo. Para resolver el problema, Redis implementa el UNLINK comando, es decir, una eliminación 'sin bloqueo'.
De hecho, UNLINK es NO siempre no bloqueante/asincrónico . Si el valor es pequeño, p. el tamaño de LIST o HASH es menor que 64 , el valor se liberará inmediatamente. De esta forma, UNLINK es casi lo mismo que DEL , excepto que cuesta algunas llamadas de función más que DEL . Sin embargo, si el valor es grande, Redis coloca el valor en una lista y otro subproceso liberará el valor, es decir, el libre sin bloqueo. De esta manera, el subproceso principal tiene que sincronizarse con el subproceso de fondo, y eso también es un costo.
En conclusión, si el valor es pequeño, DEL es al menos tan bueno como UNLINK . Si el valor es muy grande, p. LIST con miles o millones de elementos, UNLINK es mucho mejor que DEL . Siempre puede reemplazar de forma segura DEL con UNLINK . Sin embargo, si encuentra que la sincronización de subprocesos se convierte en un problema (los subprocesos múltiples siempre son un dolor de cabeza), puede retroceder a DEL .
ACTUALIZACIÓN:
Desde Redis 6.0, hay una nueva configuración:lazyfree-lazy-user-del . Puede configurarlo para que sea sí y Redis ejecutará DEL comando como si ejecutara un UNLINK comando.
