Redis Stream消费者组负载均衡需满足活跃消费者、正确调用XACK、合理消息ID推进等前提，否则会退化为单点消费或消息堆积；关键在于确保每个消费者稳定完成“读→处理→XACK”闭环。
Redis Stream 的消费者组负载均衡是自动的，但必须满足几个前提条件，否则会退化成单点消费或消息堆积。
为什么 XREADGROUP 不总是轮询分发消息
看似调用 XREADGROUP 就能触发负载均衡，实际取决于消费者是否“活跃”以及消息 ID 的推进逻辑。常见错误是消费者处理完消息后没调用 XACK，导致 Redis 认为该消费者卡住，后续消息不再分发给它。
- 消费者必须显式调用
XACK，否则消息会滞留在 Pending 列表，该消费者下次XREADGROUP仍会拿到同一批 pending 消息，而非新消息 - 消费者首次调用
XREADGROUP时传入>，表示只读取未分发过的新消息；若传0-0或具体 ID，则可能重复消费或跳过消息 - Redis 不维护消费者“在线状态”，只靠
XPENDING中的 idle 时间判断超时（默认 5 分钟），超时后才通过XCLAIM转移消息
如何确认当前负载是否真的均衡
不能只看消费者进程数量，得查每个消费者在 Pending 列表里的消息数和 idle 时间。直接用 XPENDING 是最准的观测方式。
- 运行
XPENDING mystream mygroup查看总 pending 数、最小/最大 ID、idle 范围 - 加参数
XPENDING mystream mygroup - + 10 consumer1可查指定消费者最近 10 条 pending 消息详情，重点关注idle字段 - 如果某个 consumer 的 idle 值长期 > 30s，说明它处理慢或没调
XACK；如果多个 consumer 的 pending 数相差 5 倍以上，大概率存在处理能力不均或网络延迟问题
避免负载倾斜的实操要点
轮询算法本身没问题，但现实中的倾斜往往来自消费逻辑差异或资源争抢，不是 Redis 层能解决的。
- 不要让一个消费者同时处理耗时差异极大的任务（比如有的订单要查 3 个外部 API，有的只是写日志），应按业务类型拆分成不同 Stream 或不同 Group
- 消费者实例的内存/CPU 配置要一致，K8s 环境下注意 limits 和 requests 设置，避免某些 Pod 被 OOM kill 后反复重启却没清理 pending
-
XREADGROUP的COUNT参数别设太大（如 1000），容易导致单次处理时间过长、idle 累积；建议从 10～50 开始压测，再根据平均处理时长调整 - 监控必须覆盖
XPENDING结果、XINFO GROUPS中的pending和consumers字段，光看 QPS 没用
真正难的不是配置命令，而是让每个消费者稳定完成“读 → 处理 → XACK”闭环。只要有一个环节卡住，整个组的负载均衡就失效了。生产环境里，90% 的不均衡问题都出在业务代码没正确调 XACK 或异常吞掉没上报。
