XCLAIM
语法
XCLAIM key group consumer min-idle-time id [id ...] [IDLE ms] [TIME unix-time-milliseconds] [RETRYCOUNT count] [FORCE] [JUSTID] [LASTID lastid]
- 可用版本
- 5.0.0
- 时间复杂度
- O(log N)，其中N是消费者组PEL中的消息数量。
- ACL 类别
-
@write,@stream,@fast,
在流消费者组的上下文中，此命令更改待处理消息的所有权，以便新所有者是作为命令参数指定的消费者。通常，当以下情况发生时会发生这种情况：
- 有一个与消费者组关联的流。
- 一些消费者A通过
XREADGROUP从流中读取消息，在该消费者组的上下文中。 - 作为副作用，在消费者组的待处理条目列表（PEL）中创建了一个待处理消息条目：这意味着消息已传递给给定消费者，但尚未通过
XACK确认。 - 然后该消费者突然永远失效。
- 其他消费者可以使用
XPENDING命令检查已过时相当长时间的待处理消息列表。为了继续处理这些消息，他们使用XCLAIM来获取消息的所有权并继续。消费者还可以使用XAUTOCLAIM命令自动扫描和认领已过时的待处理消息。
在 流简介文档 中清楚地解释了这种动态。
请注意，只有当消息的空闲时间大于我们调用 XCLAIM 时指定的最小空闲时间时，才会认领该消息。因为作为副作用，XCLAIM 还会重置空闲时间（因为现在有一个新的所有者尝试处理该消息），所以两个消费者试图同时认领同一消息将永远不会同时成功：只有一个会成功认领消息。这避免了我们以简单的方式多次处理给定消息（但在一般情况下，多次处理是可能且不可避免的）。
此外，作为副作用，XCLAIM 将增加消息尝试传递的计数，除非指定了 JUSTID 选项（它只传递消息 ID，不传递消息本身）。这样，由于某种原因无法处理的消息（例如，因为消费者在尝试处理它们时崩溃），将开始具有更大的计数，并且可以在系统内部检测到。
在以下情况下，XCLAIM 不会认领消息：
- 该消息不存在于组 PEL 中（即它从未被任何消费者读取过）。
- 该消息存在于组 PEL 中，但不在流本身中（即该消息已被读取，但从未确认，然后从流中删除，要么通过修剪，要么通过
XDEL）。
在这两种情况下，回复将不包含对应于该消息的条目（即回复数组的长度可能小于提供给 XCLAIM 的 ID 数量）。在后一种情况下，该消息也将从找到它的 PEL 中删除。此功能是在 Redis 7.0 中引入的。
命令选项
该命令有多个选项，但大多数主要用于内部使用，以便将 XCLAIM 或其他命令的效果传递给 AOF 文件并将相同的效果传播到副本，并且不太可能对普通用户有用。
IDLE <ms>: 设置消息的空闲时间（上次传递时间）。如果未指定 IDLE，则假定 IDLE 为 0，也就是说，时间计数将被重置，因为该消息现在有一个新的所有者尝试处理它。TIME <ms-unix-time>: 这与 IDLE 相同，但它不是相对的毫秒数，而是将空闲时间设置为特定的 Unix 时间（以毫秒为单位）。这对于重写 AOF 文件生成XCLAIM命令很有用。RETRYCOUNT <count>: 将重试计数器设置为指定的值。每次消息再次传递时，此计数器都会递增。通常XCLAIM不会更改此计数器，它仅在调用 XPENDING 命令时提供给客户端：这样客户端可以检测异常，例如由于某种原因在大量传递尝试后从未处理的消息。FORCE: 即使某些指定的 ID 尚未在分配给其他客户端的 PEL 中，也会在 PEL 中创建待处理消息条目。但是，消息必须存在于流中，否则非现有消息的 ID 将被忽略。JUSTID: 仅返回成功认领消息的 ID 数组，而不返回实际的消息。使用此选项意味着重试计数器不会递增。
示例
> XCLAIM mystream mygroup Alice 3600000 1526569498055-0
1) 1) 1526569498055-0
2) 1) "message"
2) "orange"
在上面的示例中，我们认领了 ID 为 1526569498055-0 的消息，只有在消息至少闲置一小时且原始消费者或其他消费者没有进行任何进度（确认或认领它）时，才会认领该消息，并将所有权分配给消费者 Alice。
RESP2/RESP3 响应
以下任何一种