在流的消费者组上下文中，此命令改变待处理消息的所有权， 因此新的所有者是在命令参数中指定的消费者。通常是这样的：

1. 假设有一个具有关联消费者组的流。
2. 某个消费者A在消费者组的上下文中通过XREADGROUP从流中读取一条消息。
3. 作为读取消息的副作用，消费者组的待处理条目列表（PEL）中创建了一个待处理消息条目：这意味着这条消息已传递给给定的消费者，但是尚未通过XACK确认。
4. 突然这个消费者出现故障，且永远无法恢复。
5. 其他消费者可以使用XPENDING检查已经过时很长时间的待处理消息列表，为了继续处理这些消息，他们使用XCLAIM来获得消息的所有权，并继续处理。

Stream介绍文档中清楚的解释了这种动态。

请注意，消息只有在其空闲时间大于我们通过XCLAIM指定的空闲时间的时才会被认领。 因为作为一个副作用，XCLAIM也会重置消息的空闲时间（因为这是处理消息的一次新尝试）， 两个试图同时认领消息的消费者将永远不会成功：只有一个消费者能成功认领消息。 这避免了我们用微不足道的方式多次处理给定的消息（虽然一般情况下无法完全避免多次处理）。

此外，作为副作用，XCLAIM会增加消息的尝试交付次数。通过这种方式， 由于某些原因而无法处理的消息（例如因为消费者在尝试处理期间崩溃），将开始具有更大的计数器， 并可以在系统内部被检测到。

命令选项

该命令有多个选项，但是大部分主要用于内部使用，以便将XCLAIM或其他命令的结果传递到AOF文件， 以及传递相同的结果到从节点，并且不太可能对普通用户有用：

1. IDLE <ms>: 设置消息的空闲时间（自最后一次交付到目前的时间）。如果没有指定IDLE，则假设IDLE值为0，即时间计数被重置，因为消息现在有新的所有者来尝试处理它。
2. TIME <ms-unix-time>: 这个命令与IDLE相同，但它不是设置相对的毫秒数，而是将空闲时间设置为一个指定的Unix时间（以毫秒为单位）。这对于重写生成XCLAIM命令的AOF文件很有用。
3. RETRYCOUNT <count>: 将重试计数器设置为指定的值。这个计数器在每一次消息被交付的时候递增。通常，XCLAIM不会更改这个计数器，它只在调用XPENDING命令时提供给客户端：这样客户端可以检测到异常，例如在大量传递尝试后由于某种原因从未处理过的消息。
4. FORCE: 在待处理条目列表（PEL）中创建待处理消息条目，即使某些指定的ID尚未在分配给不同客户端的待处理条目列表（PEL）中。但是消息必须存在于流中，否则不存在的消息ID将会被忽略。
5. JUSTID: 只返回成功认领的消息ID数组，不返回实际的消息。

返回值

array-reply：

此命令以XRANGE相同的格式返回所有成功认领的消息。但如果指定了JUSTID选项， 则只返回消息的ID，不包括实际的消息。

例子：

> XCLAIM mystream mygroup Alice 3600000 1526569498055-0
1) 1) 1526569498055-0
   2) 1) "message"
      2) "orange"

在上面的例子中，我们认领ID为1526569498055-0的消息，仅当消息闲置至少一小时且没有原始消费者或其他消费者进行推进（确认或认领它）时，并将所有权分配给消费者Alice。