XPENDING

语法
XPENDING key group [[IDLE min-idle-time] start end count [consumer]]
从以下位置开始可用：
5.0.0
时间复杂度：
O（N），其中 N 是返回的元素数，因此每次调用请求少量固定的条目数为 O（1）。O（M），其中 M 是与 IDLE 过滤器一起使用时扫描的条目总数。当命令仅返回摘要且使用者列表较小时，它会在 O（1） 时间内运行;否则，迭代每个使用者需要额外的 O（N） 时间。
ACL 类别：
@read, @stream, @slow,

通过使用者组从流中获取数据，但不确认 此类数据具有创建待处理条目的效果。这是 在XREADGROUP命令，在我们的 Redis Streams 简介中甚至更好。这XACK命令 将立即从待处理条目列表 （PEL） 中删除待处理条目 因为一旦消息被成功处理，就不再需要 供 Consumer Group 跟踪并记住当前所有者 的消息。

这XPENDINGcommand 是检查待处理列表的接口 消息，因此是一个非常重要的命令，以便观察 并了解 Streams Consumer Groups 发生的情况：什么 客户端处于活动状态，哪些消息正在等待使用或查看 如果有空闲消息。此外，此命令与XCLAIM用于实施对失败的使用者的恢复 长时间，因此某些消息未被处理：一个 不同的使用者可以领取消息并继续。这样更好 在 Streams 简介和XCLAIM命令页面，此处未介绍。

XPENDING 的摘要形式

什么时候XPENDING仅使用 Key Name 和 Consumer Group 调用 name 中，它只输出给定 Consumer 组。在以下示例中，我们创建一个 Consumer Group 和 立即通过读取组来创建一个待处理的消息XREADGROUP.

> XGROUP CREATE mystream group55 0-0
OK

> XREADGROUP GROUP group55 consumer-123 COUNT 1 STREAMS mystream >
1) 1) "mystream"
   2) 1) 1) 1526984818136-0
         2) 1) "duration"
            2) "1532"
            3) "event-id"
            4) "5"
            5) "user-id"
            6) "7782813"

我们期望 consumer 组的待处理条目列表group55自 现在有一条消息：名为consumer-123获取了 消息，而不确认其处理。简单的XPENDING表单会给我们以下信息：

> XPENDING mystream group55
1) (integer) 1
2) 1526984818136-0
3) 1526984818136-0
4) 1) 1) "consumer-123"
      2) "1"

在此表单中，该命令输出此 consumer 组，即 1，后跟 pending messages 中，然后使用 至少一条待处理消息，以及它所拥有的待处理消息的数量。

XPENDING 的扩展形式

摘要提供了一个很好的概述，但有时我们对 详。为了查看所有关联了更多 信息中，我们还需要传递一系列 ID，就像我们用XRANGE和非可选 count 参数来限制数量 每次调用返回的消息数：

> XPENDING mystream group55 - + 10
1) 1) 1526984818136-0
   2) "consumer-123"
   3) (integer) 196415
   4) (integer) 1

在扩展表单中，我们不再看到摘要信息，而是在那里 是 pending entries 列表中每条消息的详细信息。为 每条消息返回四个属性：

  1. 消息的 ID。
  2. 获取消息但仍需确认消息的使用者的名称。我们将其称为消息的当前所有者。
  3. 自上次将此消息传送给此使用者以来经过的毫秒数。
  4. 此消息的传递次数。

deliveries 计数器（即数组中的第四个元素）递增 当其他 Consumer 使用XCLAIM，或者当 消息通过XREADGROUP，在访问历史记录 使用者组中的使用者（请参阅XREADGROUP页面了解更多信息）。

可以按顺序向命令传递一个额外的参数 要查看具有特定所有者的消息：

> XPENDING mystream group55 - + 10 consumer-123

但在上述情况下，输出将是相同的，因为我们有 pending 消息。但是，保留的重要内容 请注意，此作（按特定使用者进行筛选）不是 即使有许多来自许多消费者的待处理消息，效率也很低： 我们有一个全局的待处理条目列表数据结构，并且 每个 Consumer 的 S 的 Intent S S 的 Git，因此我们可以非常有效地只显示 pending for 的消息 单个使用者。

空闲时间筛选器

还可以按空闲时间过滤待处理的流条目， 以毫秒为单位（适用于XCLAIMing 尚未 处理一段时间）：

> XPENDING mystream group55 IDLE 9000 - + 10
> XPENDING mystream group55 IDLE 9000 - + 10 consumer-123

第一个情况将返回整个组的前 10 个（或更少）PEL 条目 空闲时间超过 9 秒，而在第二种情况下，只有consumer-123.

独占范围和迭代 PEL

这XPENDING命令允许遍历待处理的条目，就像XRANGE和XREVRANGE允许流的条目。您可以通过以下方式执行此作 在最后读取的待处理条目的 ID 前面加上 表示开放（独占）范围，并证明它对 命令。(

RESP2/RESP3 回复

  • 数组回复：根据 XPENDING 的调用方式，数据不同，如本页所述。

历史

  • 从 Redis 版本 6.2.0 开始：添加了IDLEoption 和 exclusive range intervals 进行设置。
为本页评分
返回顶部 ↑