当客户端因为执行具有阻塞功能的命令如BRPOP、XREAD或者WAIT被阻塞时，该命令可以通过其他连接解除客户端的阻塞。
默认情况下，客户端会被解除阻塞，就像 timeout 超时一样。当提供了额外(可选)的设置，可以指定解除阻塞的类型，可以是 TIMEOUT或者ERROR类型。当时ERROR类型时，客户端阻塞被强制解除同时收到如下报错信息：
-UNBLOCKED client unblocked via CLIENT UNBLOCK
注意：错误信息不会完全一样，但是错误代码中一定包含-UNBLOCKED字样
这个命令，在仅能使用较少连接但要监控大量keys的时候特别有用。例如，使用命令XREAD和很少连接监控多个消息流，在某个时间点，信息流消费进程需要新增一个消息流key的监控，为了避免使用更多连接，最好的方法是从连接池中停掉一个阻塞的连接，增加新的要监控的key，再重启该阻塞命令即可。
我们使用如下操作流程来实现实现这种操作：
管理进程使用额外的连接control connection在必要时执行CLIENT UNBLOCK，同时，在某一连接执行阻塞命令之前，进程执行CLIENT ID获取该连接的ID值。 当需要监控一个新增的key或者取消一个key的监控时，通过在control connection中执行CLIENT UNBLOCK+ 上一步获取ID值来解除相关连接的阻塞。监控key 执行后，可以再次执行阻塞命令即可。
上述例子以Redis streams为例介绍了操作流程，该操作流程也可以应用到其他数据结构类型
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)
*返回值
整数:
1接触阻塞成功。0客户端没有阻塞。