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,

在流使用者组的上下文中，此命令会更改所有权 待处理消息中，因此新所有者是指定为 command 参数。通常情况是这样的：

  1. 存在具有关联使用者组的流。
  2. 某些使用者 A 通过XREADGROUP从流中，在该使用者组的上下文中。
  3. 作为副作用，将在使用者组的待处理条目列表 （PEL） 中创建待处理消息条目：这意味着消息已传递给给定的使用者，但尚未通过XACK.
  4. 然后突然间，那个消费者永远失败了。
  5. 其他使用者可能会使用XPENDING命令。为了继续处理此类消息，他们使用XCLAIM以获取消息的所有权并继续。使用者还可以使用XAUTOCLAIM命令自动扫描并声明过时的待处理邮件。

Stream intro 文档中清楚地解释了这种动态。

请注意，仅当消息的空闲时间大于我们在调用XCLAIM.因为作为副作用XCLAIM也会重置空闲时间（因为这是处理消息的新尝试），两个尝试同时领取消息的消费者永远不会都成功：只有一个消费者会成功领取消息。这避免了我们以微不足道的方式多次处理给定的消息（但在一般情况下，多次处理是可能的，也是不可避免的）。

此外，作为副作用，XCLAIM将增加尝试传送消息的计数，除非JUSTID选项（仅传递消息 ID，而不传递消息本身）。这样，由于某种原因（例如，由于消费者在尝试处理它们时崩溃）而无法处理的消息将开始具有更大的计数器，并且可以在系统内部检测到。

XCLAIM在以下情况下不会认领消息：

  1. 该消息在 PEL 组中不存在（即，任何使用者从未读取过该消息）
  2. 该消息存在于组 PEL 中，但不存在于流本身中（即，该消息已被读取但从未被确认，然后通过修剪或XDEL)

在这两种情况下，回复都不会包含该消息的相应条目（即回复数组的长度可能小于提供给XCLAIM). 在后一种情况下，该消息也将从找到该消息的 PEL 中删除。此功能是在 Redis 7.0 中引入的。

命令选项

该命令有多个选项，但大多数主要用于 order 来转移XCLAIM或其他命令添加到 AOF 文件 并将相同的效果传播到副本，并且不太可能 对普通用户有用：

  1. IDLE <ms>：设置消息的空闲时间（上次投递时间）。如果未指定 IDLE，则假定 IDLE 为 0，即重置时间计数，因为消息现在有新的所有者尝试处理它。
  2. TIME <ms-unix-time>：这与 IDLE 相同，但它不是相对毫秒数，而是将空闲时间设置为特定的 Unix 时间（以毫秒为单位）。这对于重写生成 AOF 文件非常有用XCLAIM命令。
  3. RETRYCOUNT <count>：将重试计数器设置为指定值。每次再次传送消息时，此计数器都会递增。通常XCLAIM不会更改此计数器，该计数器仅在调用 XPENDING 命令时提供给客户端：这样 Client 端可以检测异常，例如在大量投递尝试后由于某种原因从未处理的消息。
  4. FORCE：在 PEL 中创建待处理消息条目，即使某些指定的 ID 尚未在分配给其他客户端的 PEL 中。但是，该消息必须存在于流中，否则将忽略不存在的消息的 ID。
  5. JUSTID：仅返回成功声明的消息的 ID 数组，而不返回实际消息。使用此选项意味着重试计数器不会递增。

例子

> XCLAIM mystream mygroup Alice 3600000 1526569498055-0
1) 1) 1526569498055-0
   2) 1) "message"
      2) "orange"

在上面的示例中，我们声明 ID 为1526569498055-0，仅当消息处于空闲状态至少一小时且原始使用者或其他使用者没有进行（确认或声明）时，并将所有权分配给使用者Alice.

RESP2/RESP3 回复

以下任何一项：

  • Array reply：指定 JUSTID 选项时，成功领取的消息 ID 数组。
  • Array reply：流条目数组，每个条目都包含一个由两个元素组成的数组，即条目 ID 和条目数据本身。

为本页评分
返回顶部 ↑