Antes de discutir qual é o melhor, vamos dar uma olhada na diferença entre esses comandos. Ambos DEL e UNLINK libere a peça chave no modo de bloqueio. E a diferença é a forma como eles liberam a parte de valor.

DEL sempre libera a parte do valor no modo de bloqueio. No entanto, se o valor for muito grande, por ex. muitas alocações para uma grande LIST ou HASH , ele bloqueia o Redis por um longo tempo. Para resolver o problema, o Redis implementa o UNLINK comando, ou seja, uma exclusão 'sem bloqueio'.

Na verdade, UNLINK é NEM sempre não bloqueante/assíncrono . Se o valor for pequeno, por ex. o tamanho de LIST ou HASH é menor que 64 , o valor será liberado imediatamente. Desta forma, UNLINK é quase o mesmo que DEL , exceto que custa algumas chamadas de função a mais do que DEL . No entanto, se o valor for grande, o Redis colocará o valor em uma lista e o valor será liberado por outro encadeamento, ou seja, o sem bloqueio. Dessa forma, o thread principal precisa fazer alguma sincronização com o thread de segundo plano, e isso também é um custo.

Em conclusão, se o valor for pequeno, DEL é pelo menos tão bom quanto UNLINK . Se o valor for muito grande, por ex. LIST com milhares ou milhões de itens, UNLINK é muito melhor que DEL . Você sempre pode substituir DEL com segurança com UNLINK . No entanto, se você achar que a sincronização de threads se torna um problema (multi-threading é sempre uma dor de cabeça), você pode reverter para DEL .

ATUALIZAÇÃO:

Desde o Redis 6.0, há uma nova configuração:lazyfree-lazy-user-del . Você pode definir como sim , e o Redis executará o DEL comando como se estivesse executando um UNLINK comando.