XAUTOCLAIM

用法
XAUTOCLAIM key group consumer min-idle-time start [ COUNT count ] [ JUSTID ]
复杂度
如果 COUNT 很小,则为 O(1)。
6.2.0
ACL 类别
@stream, @write, @fast

此命令将符合指定条件的待处理流条目的所有权进行转移。从概念上讲,XAUTOCLAIM 等同于先调用 XPENDING 再调用 XCLAIM,但它通过类 SCAN 的语义提供了一种更直接的方式来处理消息投递失败。

XCLAIM 类似,该命令对 <key> 处的流条目以及在提供的 <group> 上下文中操作。它将待处理时间超过 <min-idle-time> 毫秒且 ID 等于或大于 <start> 的消息的所有权转移给 <consumer>

可选的 <count> 参数,默认为 100,是命令尝试认领的条目数量的上限。在内部,命令从 <start> 开始扫描消费者组的待处理条目列表 (PEL),并过滤掉空闲时间小于或等于 <min-idle-time> 的条目。命令扫描的待处理条目最大数量是 <count> 值的 10 倍(硬编码)。因此,认领的条目数量可能少于指定的值。

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

命令以数组形式返回被认领的条目。它还返回一个流 ID,用于游标式使用,作为其后续调用的 <start> 参数。当没有剩余的 PEL 条目时,命令返回特殊的 0-0 ID 来表示完成。然而请注意,即使扫描完成后以 0-0 作为 <start> ID,您可能仍希望继续调用 XAUTOCLAIM,因为时间已经足够长,所以较旧的待处理条目现在可能符合认领条件。

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

在遍历 PEL 时,如果 XAUTOCLAIM 碰到流中不再存在的消息(已被裁剪或通过 XDEL 删除),它不会认领该消息,并会将其从发现它的 PEL 中删除。这些消息 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 没有碰到任何已删除的消息(第三个回复元素是一个空数组)。

RESP2/RESP3 回复

数组回复,具体而言,是一个包含三个元素的数组

  1. 一个流 ID,用作下次调用 XAUTOCLAIM 的 start 参数。

  2. 一个数组回复,其中包含所有成功认领的消息,格式与 XRANGE 相同。

  3. 一个数组回复,其中包含流中不再存在且已从发现它们的 PEL 中删除的消息 ID。

历史

版本 更改
7.0.0

在回复数组中添加了一个元素,包含命令从 PEL 中清除的已删除条目