Redis Stream 消费组为什么重复收到消息

Redis Stream 消费组重复收到同一条消息，最常见的原因不是 Stream 自己复制了数据，而是消费者已经读到消息，却在业务处理完成前崩溃、超时或没有执行 XACK。消息会留在消费者组的 Pending Entries List（PEL）里，之后被同一个消费者恢复读取，或被其他消费者接管，于是业务侧看到第二次投递。

官方地址：https://redis.io/docs/latest/develop/data-types/stream/

排查时先回答一个问题：重复的是同一个消息 ID，还是业务字段相同但其实是两条消息？如果消息 ID 相同，优先查 PEL、确认时机和转交策略；如果 ID 不同，再查生产端是否重复写入。

先判断：重复消息是不是 PEL 重投

消费者组使用 XREADGROUP 读取消息后，Redis 会记录消息 ID、消费者归属和投递状态。业务处理成功并执行 XACK 后，消息才会从这个组的 PEL 中移除；消息是否还留在 Stream，是另一个保留问题。因此，先拿重复消息的 ID 对照 XPENDING，不要只看 XLEN。

# 查看 orders 消费者组的待确认摘要；返回值只用于说明查询形状。
redis-cli XPENDING orders workers

# 按消息 ID 查询一小段明细，观察消费者、空闲时间和投递次数。
redis-cli XPENDING orders workers 1710000000000-0 1710000000000-0 COUNT 1

# 只筛选空闲超过 60 秒的记录；IDLE 的单位是毫秒。
redis-cli XPENDING orders workers IDLE 60000 - + COUNT 20

如果重复消息的 ID 出现在 PEL 明细中，说明它不是“读完就自动删除”，而是上次投递还没有完成确认。摘要里的总数、最小/最大 ID 和消费者分布适合快速判断，明细里的空闲时间与投递次数则用于定位恢复、卡死或确认失败。

区分新消息读取和待处理消息读取

XREADGROUP 的最后一个 ID 决定读取语义。使用 > 时，消费者组读取的是从未投递给任何消费者的新消息；使用 0 或其他具体 ID 时，读取的是当前消费者名下仍在 PEL 中的历史待处理消息。把这两个入口混在一起，恢复程序就容易把“重试旧消息”误认为“消费到新消息”。

# 读取 workers 组尚未投递过的新消息；成功处理后再执行 XACK。
redis-cli XREADGROUP GROUP workers worker-1 COUNT 10 BLOCK 5000 STREAMS orders >

# 恢复 worker-1 自己名下的 PEL 消息；这里只表示读取，不代表处理成功。
redis-cli XREADGROUP GROUP workers worker-1 COUNT 10 STREAMS orders 0

因此，应用日志至少要同时记录 Stream 键、消费者组、消费者名、消息 ID、业务幂等键、开始处理时间和确认结果。只打印业务订单号不够，因为订单号可能相同，而 Redis 是否重复投递要靠消息 ID 判断。

从空闲时间定位重复投递的触发点

看到同一个 ID 第二次出现时，先看它在 PEL 中的空闲时间和投递次数，再对照消费者心跳。空闲时间很短，可能是处理线程超时后快速重试；空闲时间很长，常见原因是消费者进程退出、连接断开，或者业务处理成功但确认请求没有发出去。

这里的关键判断是：XACK 只改变消费者组的待处理状态，不会替业务撤销已经执行的副作用。因此“确认成功”不能替代支付、发货、写库等业务动作的幂等设计。

长期空闲消息怎么转交才不会放大重复

确认原消费者确实失联，并且业务允许重试后，才使用 XAUTOCLAIM 或 XCLAIM。XAUTOCLAIM 按最小空闲时间寻找并改变消息归属；XCLAIM 适合已经知道具体消息 ID 的场景。二者都不是删除消息的命令，新的消费者处理成功后仍要执行 XACK。

# 只接管空闲至少 60 秒的少量消息，降低恢复时的并发冲击。
redis-cli XAUTOCLAIM orders workers worker-2 60000 0-0 COUNT 10

# 已确认具体 ID 且需要定向接管时使用 XCLAIM。
redis-cli XCLAIM orders workers worker-2 60000 1710000000000-0

# 业务处理成功后收口；直接 XACK 不会替你完成业务动作。
redis-cli XACK orders workers 1710000000000-0

恢复消费者必须按业务键做幂等，例如把订单号或事件唯一键作为数据库唯一约束、去重表键或状态机条件。推荐顺序是“接管后读取消息 → 检查幂等记录 → 尚未成功才执行业务 → 记录结果 → XACK”。图中的连线是静态关系说明，不表示 Redis 会自动按这个顺序替你完成业务。

回滚、告警和复盘要留下什么

恢复动作不要一次性接管整个 PEL。先用较小的 COUNT 和明确的空闲阈值处理一批，观察重复副作用、处理延迟和 XACK 成功率；如果业务出现异常，暂停恢复消费者，保留未确认记录，回滚的是“继续转交”的动作，而不是直接删除 PEL。

告警至少区分四个指标：PEL 总数、最长空闲时间、每个消费者的待处理数、同一消息 ID 的投递次数。Stream 长度增长不等于消费者组积压，PEL 归零也不代表业务副作用没有重复。复盘时保留消息 ID、业务幂等键、原消费者、接管消费者、处理结果和 XACK 时间，才能把“重复收到”还原成具体的一次故障链。

常见问题

为什么 Stream 里还能看到消息，PEL 却没有它？ Stream 的保留和消费者组的确认是两个维度。消息还可以留在 Stream 中，但已经被该组确认；也可能消息被裁剪后，应用仍需根据 PEL 和业务记录判断是否补偿。

把消费者名改掉能避免重复吗？ 不能。改名可能让恢复逻辑看起来像新消费者，但没有解决未确认、超时和业务幂等问题，还可能让排障更难。

能不能直接 XACK 来消除重复？ 只有在确认业务结果已经成功或明确决定放弃处理时才可以。直接 XACK 只是移除 PEL 记录，不会补做业务，也不会撤销已经发生的副作用。

归纳起来，Redis Stream 的重复投递应按“消息 ID → XPENDING → 消费者与空闲时间 → 幂等处理 → XAUTOCLAIM/XCLAIM → XACK”的顺序判断。把它当作至少一次投递来设计，重复就会从不可解释的线上现象，变成可以定位、限流和收口的运行事件。