来源：Redislabs
作者：Kyle Davis
翻译：Kevin (公众号：中间件小哥）
Redis 4.0给Redis生态带来了一个惊人的功能：Modules（模块）。Modules是Redis的一大转变，它是Redis内部自定义数据类型和全速计算的开放环境。但是，尽管对该版本的大多数关注都集中在Modules上，但新版本还引入了一个非常重要的命令，它就是游戏规则的改变者：UNLINK。
您可以使用redis-cli连接redis-server执行info命令，去查看当前redis版本中是否可以使用UNLINK命令。info响应将告诉您有关服务器的所有信息。在第一部分（#Server）中，返回结果有一行值为redis_version。如果该值大于4.0，则可以使用UNLINK命令。并非所有Redis提供商都保持最新版本，因此最好在更改代码之前检查redis版本。
让我们回顾一下Redis的关键架构功能之一：“单线程”。Redis在大多数情况下是一个单线程应用程序。它一次只做一件事，这样可以把这些事做的更快。多线程有点复杂，并且引入了锁和其他可能降低应用程序速度的问题。尽管Redis（最高4.0版）通过多线程方式执行了少量操作，但它通常在启动另一个命令之前先要完成一个命令。
相比于快速读写，您可能会觉得使用DEL命令去删除一个键值不需要考虑太多，但是在很多情况下，删除数据同样很重要。与Redis中的大多数命令一样，DEL命令在单个线程中运行，如果您获取一个几千字节的键值，花费不到一毫秒的时间，这是您所感知不到的。然而，当您获取的键值大小是兆字节、100兆字节或者500兆字节会发生什么呢？哈希、排序、列表等数据结构会随着时间的推移而添加更多的数据进去，这样会生成一个数GB大小的数据集。然后用DEL命令去删除大Key时会发生什么呢？由于Redis是单线程操作的，处理这种请求时整个服务都处于等待中，需要等待该命令执行完成才能执行其它操作。同时，我们考虑更复杂的一种场景，这些键中保存的数据可能已经包含数以千万个微小请求，因此应用程序或操作员可能无法真正了解删除这些数据需要花费多长时间。
理智会告诉我们不要在拥有100万元素的排序集上运行如下这样的命令：
> ZRANGE some-zset 0 -1
但是，在上面的some-zset集合中执行DEL命令将花费和上面一样的时间-中间没有传输开销，但是它会一直去分配内存，而且您会一直卡死在CPU繁忙中。在使用UNLINK之前，您可能会结合SCAN命令采用非原子性的方法进行一些少量删除，去避免这种持续分配内存的噩梦。上面无论使用哪种方式，都是让人无法接受的。
您可能已经猜到了，就是使用UNLINK命令来替换DEL！从语法上讲，UNLINK与DEL相同，但UNLINK提供了更为理想的解决方案。首先，它将键值从整个键值空间中删除。然后，在另一个线程中，它开始回收内存。从多线程的角度来看，这是一种安全的操作，因为它（在主线程中）从键空间中删除了该项，从而使Redis其它命令无法访问。
如果你有一个快速增长的键值-不管键值的大小如何，UNLINK都是O（1）操作（每个键；在主线程中）。使用DEL删除一个大值可能需要几百毫秒或更长时间，而UNLINK将在不到一毫秒的时间内完成（包括网络往返）。当然，您的服务器仍将需要花一些时间在另一个线程中重新分配该值的内存（其中的工作是O（N），其中N是已删除值的分配数），但是主线程的性能不会被另一个线程中正在进行的操作严重影响到。
因此，您是否应该用UNLINK命令替换代码中的所有DEL命令？当然，在少数情况下，DEL正是您所需要的。这里我可以想到两点：
1、 在MULTI / EXEC或pipeline中，在添加和删除大值时DEL命令是一种理想选择。在这种情况下，UNLINK不会立即释放空间，并且在处理繁忙的情况下（如果内存已满），您可能会遇到麻烦。
2、 在更紧急的情况下，在无快速响应驱逐数据下您可以写入数据。
在没有极端内存限制的理想环境中，很难想到不使用UNLINK的情况。UNLINK将提供更一致的行为，总体上具有更好的性能，并且代码更改非常小（如果可以在客户端中重命名命令，则无需更改）。如果UNLINK适合您的应用程序，请就此将您的DEL更改为UNLINK，然后查看它的性能提高。
更多优质中间件技术资讯/原创/翻译文章/资料/干货，请关注“中间件小哥”公众号！