Redis XREADGROUP 怎样限制多流读取总量

用消费组同时读取多条 Redis Stream 时，最容易误判的是 COUNT 的作用范围：它限制的是每一条流返回的条数，不是整条命令的总条数。比如同时读 3 条流并设置 COUNT 20，理论上一次回复最多可能包含 60 条消息。需要把总工作量压在一个明确预算内时，应使用 Redis 8.10 起提供的 MAXCOUNT，它把多条流的返回条数放进同一个累计上限。

官方命令文档：https://redis.io/docs/latest/commands/xreadgroup/。下面只讨论多流读取上限，不把 Stream 裁剪、消费组创建和消息确认混进同一个问题。

先算清 COUNT 到底限制了什么

XREADGROUP 的 STREAMS 后面可以放多条流和对应的 ID。COUNT C 是每条流最多返回 C 条，因此总量上界要先乘以流数；实际返回量还会受每条流可读消息数影响，但不会因为 COUNT 自动变成一个全局预算。

例如，三条流分别是 orders:shenzhen、orders:hangzhou 和 orders:beijing。下面的命令只表达“每条流最多取 20 条”，并没有表达“总共最多取 20 条”。

# COUNT 是每条 Stream 的上限；三条流的理论总量最多为 3 × 20。
redis-cli XREADGROUP GROUP orders worker-a COUNT 20 STREAMS \
  orders:shenzhen orders:hangzhou orders:beijing '>' '>' '>'

如果消费者每次处理一批消息、批内任务会占用固定内存或下游接口有请求上限，就不能只看 COUNT 的数字。先明确“每流公平性”还是“整次批量预算”，再选择参数。

用 MAXCOUNT 给整次读取设置总条数

MAXCOUNT 是跨所有流的累计条数上限。仍然使用三条流时，COUNT 20 MAXCOUNT 30 表示单流最多 20 条，同时整条回复最多 30 条；如果只关心总量，也可以省略 COUNT，让 MAXCOUNT 单独作为预算。

# COUNT 控制单流上限，MAXCOUNT 控制这次命令跨流的总条数。
redis-cli XREADGROUP GROUP orders worker-a COUNT 20 MAXCOUNT 30 STREAMS \
  orders:shenzhen orders:hangzhou orders:beijing '>' '>' '>'

# 只限制总量；Redis 会从给出的流集合中按命令语义填充，最多返回 30 条。
redis-cli XREADGROUP GROUP orders worker-a MAXCOUNT 30 STREAMS \
  orders:shenzhen orders:hangzhou orders:beijing '>' '>' '>'

两者同时使用时，MAXCOUNT 必须大于或等于 COUNT。这是因为 COUNT 先给每条流划出局部上限，MAXCOUNT 再给所有流设置累计预算。若想要每条流都至少有机会拿到一部分消息，应继续保留 COUNT；若下游只接受固定大小的批次，优先把 MAXCOUNT 设为真正的全局预算。

新消息和待处理消息要用同一套预算思路

STREAMS 后的 > 表示读取还没有交给任何消费者的新消息；传入具体 ID 则是在消费组的待处理列表（PEL）中读取属于当前消费者的历史消息。两种读取都可能跨多个流，所以“总条数不能超过预算”的设计不能只写在新消息分支里。

如果消费者需要等待新消息，可以叠加 BLOCK。它只决定没有可读数据时等待多久，不会把 COUNT 变成全局上限，也不会替代 MAXCOUNT。处理 PEL 时则应根据重试批次单独决定 ID 范围和预算，避免恢复任务与正常消费共用一个不可解释的批量大小。

# 等待新消息；BLOCK 只控制等待时间，MAXCOUNT 仍控制跨流总条数。
redis-cli XREADGROUP GROUP orders worker-a COUNT 20 MAXCOUNT 30 BLOCK 5000 STREAMS \
  orders:shenzhen orders:hangzhou orders:beijing '>' '>' '>'

还要注意，设置了条数上限不等于消息已经处理成功。使用 > 读取的消息进入当前消费者的 PEL，后续仍需要按业务结果决定确认或重试；文章里的“限制读取总量”只描述一次回复的规模，不替代确认策略。

消息条数不够时再考虑 MAXSIZE

消息字段大小差异很大时，即使条数固定，回复体积仍可能波动。Redis 8.10 起可以用 MAXSIZE 限制跨所有流的回复字节数；当 MAXCOUNT 和 MAXSIZE 同时存在时，先达到的边界生效。字节预算不会为了返回空结果而跳过第一条消息，所以单条消息本身大于预算时，仍可能先返回这一条。

# 同时限制条数和回复字节数；更早达到的边界优先。
redis-cli XREADGROUP GROUP orders worker-a COUNT 20 MAXCOUNT 30 MAXSIZE 1048576 STREAMS \
  orders:shenzhen orders:hangzhou orders:beijing '>' '>' '>'

这类参数需要和 Redis 服务端版本、客户端命令构造能力一起确认。旧版本不认识 MAXCOUNT 或 MAXSIZE 时，不能把参数静默降级后继续宣称“全局限流”；应在部署约束中明确版本，或在应用层把多流读取拆成可计算的单流批次。

按负载选择一套可解释的配置

实际落地时可以把“单次最多处理多少条”“最多接受多少字节”“一次涉及多少条流”“新消息还是 PEL”记录在同一份配置说明中。这样批量参数变化时，读者能追溯它影响的是公平性、总工作量还是响应体大小，而不会把 COUNT 的局部限制误读成全局保护。

多流读取上限的几个常见疑问

COUNT 20 能保证三条流总共只返回 20 条吗？

不能。它最多约束每条流各 20 条；要限制整次回复，应使用 MAXCOUNT。

MAXCOUNT 能替代 COUNT 吗？

可以只使用 MAXCOUNT 做累计预算，但这时没有单流上限。需要避免某一条流占满批次时，再同时设置 COUNT。

BLOCK 设得更小能减少一次返回量吗？

不能。BLOCK 是等待时间参数，返回量仍由 COUNT、MAXCOUNT、MAXSIZE 和可读数据共同决定。

最后记住一个判断顺序：先确认流数量，再计算 COUNT 的可能总量；需要跨流预算就加 MAXCOUNT；消息大小差异明显再加 MAXSIZE；最后单独处理 BLOCK、PEL 和确认策略。