XINFO GROUPS

XINFO GROUPS key

可用版本

5.0.0

时间复杂度

O(1)

ACL 类别

@read, @stream, @slow,

该命令返回存储在 <key> 的流的所有消费者组列表。

默认情况下，每个组只提供以下信息：

• name: 消费者组名称
• consumers: 组中的消费者数量
• pending: 组的待处理条目列表（PEL）的长度，这些是已传递但尚未确认的消息
• last-delivered-id: 传递给组的消费者的最后一个条目的 ID
• entries-read: 传递给组的消费者的最后一个条目的逻辑“读取计数器”
• lag: 流中仍等待传递给组的消费者的条目数量，或者在该数量无法确定时为 NULL。

消费者组延迟

给定消费者组的延迟是指组的 entries_read 和流的 entries_added 之间的范围内的条目数量。换句话说，它是尚未传递给组的消费者的条目数量。

该指标的值和趋势有助于做出有关消费者组的扩展决策。可以通过向组添加更多消费者来解决高延迟值，而低延迟值可能表明可以从组中移除消费者以缩减规模。

Redis 通过保持两个计数器来报告消费者组的延迟：添加到流中的所有条目的数量和消费者组进行的逻辑读取次数。延迟是这两个值之间的差值。

流的计数器（XINFO STREAM 命令的 entries_added 字段）在每次执行 XADD 操作时增加 1，并统计其整个生命周期内添加到流中的所有条目。

消费者组的计数器 entries_read 是组读取的条目的逻辑计数器。重要的是要注意，此计数器只是一个启发式方法，而不是一个准确的计数器，因此使用“逻辑”一词。该计数器试图反映组应该读取的条目数量以达到其当前的 last-delivered-id。只有在理想情况下，entries_read 计数器才是准确的，在这种情况下，消费者组从流的第一个条目开始并处理其所有条目（即，在处理之前没有条目被删除）。

有两种特殊情况，这种机制无法报告延迟

1. 消费者组是用一个任意的最后一个传递的 ID 创建或设置的（分别为 XGROUP CREATE 和 XGROUP SETID 命令）。任意 ID 是任何不是流的第一个条目的 ID、最后一个条目或零 (“0-0”) ID 的 ID。
2. 组的 last-delivered-id 和流的 last-generated-id 之间的条目被删除了一个或多个（使用 XDEL 或修剪操作）。

在这两种情况下，组的读取计数器都被认为是无效的，并且返回的值被设置为 NULL 以指示当前无法获取延迟。

但是，延迟只是暂时不可用。当消费者继续处理消息时，它会在常规操作期间自动恢复。一旦消费者组将其最后一个消息传递给其成员，它将使用正确的逻辑读取计数器进行设置，并且可以恢复跟踪其延迟。

示例

> XINFO GROUPS mystream
1)  1) "name"
    2) "mygroup"
    3) "consumers"
    4) (integer) 2
    5) "pending"
    6) (integer) 2
    7) "last-delivered-id"
    8) "1638126030001-0"
    9) "entries-read"
   10) (integer) 2
   11) "lag"
   12) (integer) 0
2)  1) "name"
    2) "some-other-group"
    3) "consumers"
    4) (integer) 1
    5) "pending"
    6) (integer) 0
    7) "last-delivered-id"
    8) "1638126028070-0"
    9) "entries-read"
   10) (integer) 1
   11) "lag"
   12) (integer) 1

RESP2/RESP3 响应

历史

• 从 Redis 版本 7.0.0 开始：添加了 entries-read 和 lag 字段