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 的语义来处理消息传递失败。

与 XCLAIM 一样，该命令对<key> 中的流条目进行操作，并在提供的 <group> 的上下文中进行操作。它将挂起消息的所有权转移到 <consumer>，这些消息已挂起超过 <min-idle-time> 毫秒，并且其 ID 大于或等于 <start>。

可选的 <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 中删除。此功能是在 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 没有偶然发现任何已删除的消息（第三个回复元素是一个空数组）。

RESP2/RESP3 回复

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

  1. 一个流 ID，将用作下一次调用 XAUTOCLAIM 的start 参数。
  2. 一个 数组回复，包含所有成功索取的消息，格式与 XRANGE 相同。
  3. 包含不再存在于流中的消息 ID 的 数组回复，这些消息 ID 已从找到它们的 PEL 中删除。

历史

  • 从 Redis 7.0.0 版本开始：在回复数组中添加了一个元素，其中包含该命令从 PEL 中清除的已删除条目。
RATE THIS PAGE
Back to top ↑