CLIENT UNBLOCK

此命令可以从不同的连接解除被阻塞客户端的阻塞，这些客户端可能阻塞在诸如 BRPOP、XREAD 或 WAIT 等阻塞操作中。

默认情况下，客户端解除阻塞的方式如同命令已达到超时。但是，如果传入一个额外的（可选）参数，则可以指定解除阻塞的行为，可以是 TIMEOUT（默认）或 ERROR。如果指定 ERROR，则行为是解除客户端的阻塞，并返回一个错误，表明客户端已被强制解除阻塞。具体来说，客户端将收到以下错误：

-UNBLOCKED client unblocked via CLIENT UNBLOCK

注意：当然，通常不能保证错误文本保持不变，但错误代码将始终是 -UNBLOCKED。

此命令特别有用，尤其是在我们使用有限数量的连接监视许多键时。例如，我们可能希望使用 XREAD 监视多个流，而无需使用超过 N 个连接。然而，在某个时候，消费者进程会收到通知，告知有一个新的流键需要监视。为了避免使用更多连接，最佳行为是停止连接池中某个连接上的阻塞命令，添加新键，然后再次发出阻塞命令。

为了实现此行为，可以使用以下模式。进程使用一个额外的控制连接来在需要时发送 CLIENT UNBLOCK 命令。同时，在其他连接上运行阻塞操作之前，进程会运行 CLIENT ID 以获取与该连接关联的 ID。当需要添加新键，或当某个键不再需要监视时，通过在控制连接中发送 CLIENT UNBLOCK 来中止相关连接的阻塞命令。阻塞命令将返回，并最终可以重新发出。

此示例展示了在流上下文中的应用，但此模式是通用的，可以应用于其他情况。

示例

Connection A (blocking connection):
> CLIENT ID
2934
> BRPOP key1 key2 key3 0
(client is blocked)

... Now we want to add a new key ...

Connection B (control connection):
> CLIENT UNBLOCK 2934
1

Connection A (blocking connection):
... BRPOP reply with timeout ...
NULL
> BRPOP key1 key2 key3 key4 0
(client is blocked again)

RESP2/RESP3 回复

以下之一

• 整数回复：如果客户端成功解除阻塞，则为 0。

• 整数回复：如果客户端未被解除阻塞，则为 1。