多个 consumer group 怎样分别重放事件

可以。Redis Stream 的多个 consumer group 共享同一条事件流，但每个组都有自己的 last-delivered-id 和 PEL（Pending Entries List）。因此，订单组可以继续消费新事件，审计组则从历史 ID 开始重放，两个进度互不覆盖。

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

最稳妥的做法是：为不同业务建立不同 consumer group；一次性历史回放优先创建新的回放组并从 0-0 开始，复用旧组前先检查 PEL，不能把 XGROUP SETID 当成清空未确认消息。

一条 Stream 为什么能让多个组各自读到同一批事件

consumer group 内部的消费者会分摊消息，但 group 之间不是分摊关系。Redis 会把同一条 Stream 的事件分别交给每个组维护自己的游标，所以 billing-group 读过的事件，不会让 audit-group 失去回放机会。

排查时先建立三项基线：Stream 的首尾 ID、每个组的 last-delivered-id、每个组的 PEL 数量。回放完成的判断也对应这三项，而不是只看某个消费者是否打印了日志。

创建两个组并分别选择起始位置

假设事件流名为 app:events。业务组从现在开始接收，回放组从流头读取，可以这样创建：

# 业务组只接收创建之后尚未投递的新事件
redis-cli XGROUP CREATE app:events billing-group $ MKSTREAM

# 回放组从 Stream 开头建立独立游标
redis-cli XGROUP CREATE app:events audit-replay 0-0 MKSTREAM

# 每个组都使用自己的 consumer 名称，避免把 PEL 归到错误的消费者
redis-cli XREADGROUP GROUP billing-group worker-1 COUNT 100 STREAMS app:events >
redis-cli XREADGROUP GROUP audit-replay replay-worker COUNT 100 STREAMS app:events >

这里的 > 只表示读取该组尚未投递的新消息；它不是“读取整个 Stream”。回放组的初始游标已经是 0-0，所以它可以从历史事件开始，而业务组仍停留在自己的实时消费位置。

回放时最容易混淆的是组游标和 PEL

已有组要重新从头处理时，可移动该组的最后投递 ID：

# 只重置 audit-replay，不影响 billing-group
redis-cli XGROUP SETID app:events audit-replay 0-0

# 回放完成后用 XINFO 观察该组的游标变化
redis-cli XINFO GROUPS app:events

# 读取指定 consumer 的未确认历史；具体 ID 读取的是 PEL，不是新消息
redis-cli XREADGROUP GROUP audit-replay replay-worker COUNT 100 STREAMS app:events 0-0

XGROUP SETID 改的是组游标，旧的未确认引用仍可能留在 PEL。若旧组有失败重试、多个消费者或长时间积压，建议创建类似 audit-replay-20261025 的新组，从 0-0 开始，回放结束后再按保留策略销毁它。这样不会把历史重放和线上消费的未确认状态混在一起。

用指标确认两个组确实独立回放

不要用“命令返回 OK”作为唯一结果。至少分别记录两个组的状态，再比较回放前后的变化：

一组完成回放后，应该看到它的游标向流尾推进，且业务处理成功的消息通过 XACK 从该组 PEL 移除；另一个组的游标和 PEL 不应因为这次操作被改写。若 Stream 已经被 XTRIM 删除了早期事件，任何 consumer group 都不能凭空回放那些已不存在的条目。

常见边界问题

多个 consumer 放在同一个组里，会各自拿到完整历史吗？不会。同一组内的消费者是分工关系，消息会在组内分摊；要让两套业务都得到完整事件集合，应创建两个 group。

为什么用具体 ID 读取不到新消息？XREADGROUP 使用具体 ID 时是在访问该 consumer 的 pending history，只有 > 才请求该组尚未投递的新消息。要做稳定回放，优先使用独立回放组，并把组的 PEL 数量和游标一起纳入验收。