XINFO 组

语法
XINFO GROUPS key
从以下位置开始可用：
5.0.0
时间复杂度：
O（1）
ACL 类别：
@read, @stream, @slow,

此命令返回存储在<key>.

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

  • name：Consumer Group 的名称
  • consumers：Group 中的 Consumer 数量
  • pending：组的待处理条目列表 （PEL） 的长度，这些列表是已送达但尚未确认的消息
  • last-delivered-id：传送给组使用者的最后一个条目的 ID
  • entries-read：传递给组的消费者的最后一个条目的逻辑 “read counter”
  • lag：流中仍等待传送给组使用者的条目数，如果无法确定该数量，则为 NULL。

消费组滞后

给定使用者组的滞后是该组的entries_read和流的entries_added. 换句话说，它是尚未交付给该组消费者的条目数量。

此指标的值和趋势有助于做出有关使用者组的扩展决策。 您可以通过向组添加更多使用者来解决高滞后值，而低值可能表示您可以从组中删除使用者以缩小组。

Redis 通过保留两个计数器来报告使用者组的滞后：添加到流中的所有条目数和使用者组进行的逻辑读取数。 滞后是这两者之间的差异。

流的计数器 （entries_added字段的XINFO STREAMcommand） 递增 1，每个XADD并计算在流的生命周期内添加到流中的所有条目。

consumer group 的计数器entries_read是组已读取的条目的逻辑计数器。 需要注意的是，这个计数器只是一个启发式的，而不是一个准确的计数器，因此使用了术语 “logical”。 计数器尝试反映组为达到其当前值而应读取的条目数last-delivered-id. 这entries_readcounter 仅在理想情况下才准确，其中 Consumer Group 从 Stream 的第一个 entry 开始并处理其所有 entry（即，在处理之前没有删除任何条目）。

在两种特殊情况下，此机制无法报告滞后：

  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：消费组列表。

历史

  • 从 Redis 版本 7.0.0 开始：添加了entries-read和lag领域
为本页评分
返回顶部 ↑