XAUTOCLAIM

语法
XAUTOCLAIM key group consumer min-idle-time start [COUNT count]
  [JUSTID]
从以下位置开始可用：
6.2.0
时间复杂度：
如果 COUNT 较小，则为 O（1）。
ACL 类别：
@write, @stream, @fast,

此命令转移与指定条件匹配的待处理流条目的所有权。概念XAUTOCLAIM等效于调用XPENDING然后XCLAIM, 而是提供了一种更直接的方法来处理消息传递失败，方法是SCAN类似语义的 Tim S 的 Tim S T

喜欢XCLAIM，该命令将对位于<key>在提供的<group>. 它将所有权转让给<consumer>的邮件待处理时间超过<min-idle-time>毫秒，并且 ID 等于或大于<start>.

可选的<count>argument（默认为 100）是命令尝试声明的条目数的上限。 在内部，该命令开始从<start>并筛选出空闲时间小于或等于<min-idle-time>. 命令扫描的待处理条目的最大数量是乘以<count>的值替换为 10（硬编码）。 因此，声明的条目数可能会小于指定的值。

可选的JUSTID参数将回复更改为仅返回成功声明的消息的 ID 数组，而不返回实际消息。 使用此选项意味着重试计数器不会递增。

该命令将声明的条目以数组的形式返回。它还返回一个流 ID，该 ID 旨在用作类似游标的<start>参数进行后续调用。 当没有剩余的 PEL 条目时，该命令将返回特殊的0-0ID 来表示完成。 但是，请注意，您可能希望继续调用XAUTOCLAIM即使在扫描完成后，使用0-0如<start>ID 的 ID 中，因为已经过去了足够的时间，因此较旧的待处理条目现在可能有资格领取。

请注意，只有空闲时间超过<min-idle-time>被认领，并且认领消息会重置其空闲时间。 这确保了只有一个使用者可以在特定时刻成功声明给定的待处理消息，并轻松降低多次处理同一消息的可能性。

在迭代 PEL 时，如果XAUTOCLAIM偶然发现一条消息，该消息在流中不再存在（由XDEL） 它不会声明它，并从找到它的 PEL 中删除它。此功能是在 Redis 7.0 中引入的。 这些消息 ID 将作为XAUTOCLAIM的回复。

最后，使用XAUTOCLAIM还会增加该消息的尝试投递计数，除非JUSTID选项（仅传递消息 ID，而不传递消息本身）。 由于某种原因（例如，由于使用者在处理消息时系统性崩溃）而无法处理的消息将表现出较高的尝试传送计数，这些计数可以通过监控来检测。

例子

> XAUTOCLAIM mystream mygroup Alice 3600000 0-0 COUNT 25
1) "0-0"
2) 1) 1) "1609338752495-0"
      2) 1) "field"
         2) "value"
3) (empty array)

在上面的示例中，我们尝试从流的开头开始，在至少一小时内声明最多 25 个处于待处理和空闲状态（未被确认或声明）的条目。 “mygroup”组中的使用者 “Alice” 获得这些消息的所有权。 请注意，示例中返回的流 ID 为0-0，表示已扫描整个流。 我们还可以看到XAUTOCLAIM没有偶然发现任何已删除的消息（第三个 reply 元素是一个空数组）。

RESP2/RESP3 回复

Array 回复，具体来说，是一个包含三个元素的数组：

  1. 一个流 ID，用作下次调用 XAUTOCLAIM 的开始参数。
  2. 一个 Array 回复，包含所有成功声明的消息，格式与XRANGE.
  3. 一个 Array 回复，其中包含流中不再存在的消息 ID，并且已从找到它们的 PEL 中删除。

历史

  • 从 Redis 版本 7.0.0 开始：向 reply 数组中添加了一个元素，其中包含命令从 PEL 中清除的已删除条目
为本页评分
返回顶部 ↑