XINFO GROUPS

Syntax
XINFO GROUPS key
Available since:
5.0.0
Time complexity:
O(1)
ACL categories:
@read, @stream, @slow,

此命令返回存储在的流的所有消费者组列表。

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

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

消费者组延迟

给定消费者组的延迟是该组的entries_read与流的entries_added之间的条目数。 换句话说，这是尚未传递给该组消费者的条目数。

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

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

流的计数器（XINFO STREAM命令的entries_added字段）每次使用XADD时都会增加一，并计算流在其生命周期内添加的所有条目。

消费者组的计数器entries_read是该组已读取条目的逻辑计数器。 需要注意的是，这个计数器只是一个启发式的而非准确的计数器，因此使用了“逻辑”这一术语。 该计数器试图反映该组应该读取的条目数量，以达到其当前的last-delivered-id。 entries_read计数器仅在一个完美的世界中是准确的，即消费者组从流的第一个条目开始并处理所有条目（即没有在处理之前删除的条目）。

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

  1. 创建或设置消费者组时，使用任意最后交付的ID（分别是XGROUP CREATE和XGROUP SETID命令）。 任意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 回复

Array reply: a list of consumer groups.

历史

  • 从 Redis 7.0.0 版本开始：添加了 entries-read 和 lag 字段
RATE THIS PAGE
Back to top ↑