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