根本原因是消费者崩溃或重启时未及时xack，导致消息滞留pel；redis默认保障“至少一次”投递，需业务层实现幂等。
消费者进程重启后，XREADGROUP 为什么还会重复消费？
根本原因不是 Redis 重启，而是消费者自身崩溃或重启时没来得及 XACK。Redis Stream 的 PEL（Pending Entries List）会保留这些“已分发但未确认”的消息，等它恢复后，若仍用 > 启动，就会跳过 PEL 里的旧消息，只拿新消息——而那些 PEL 消息会被其他消费者或下次轮询重新分发，造成“看似重复”。
这不是 bug，是设计：Stream 默认保障“至少一次”投递，靠业务层做幂等。
-
XREADGROUP GROUP mygroup consumer1 STREAMS mystream >：只读新消息，不管 PEL -
XREADGROUP GROUP mygroup consumer1 STREAMS mystream 0：从头读，包括已分配未确认的（可能重复） - 真正安全的做法是：重启后先查
XPENDING mystream mygroup，再用XCLAIM主动认领自己上次挂起的消息
如何让单个消费者重启后继续处理未完成的消息？
关键不是“避免重启”，而是让重启后的消费者能接续上次中断的位置。这依赖两个动作：主动接管 + 状态对齐。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 启动时先执行
XPENDING mystream mygroup - + 10，列出本组里所有 pending 消息，过滤出属于自己的（靠 consumer name 字段） - 对每条属于自己的 pending 消息，调用
XCLAIM mystream mygroup consumer1 3600000 1710234567890-0（第三个参数是 idle time，单位毫秒；第四个是 msg ID） - 拿到
XCLAIM返回的消息后，正常处理并XACK，不要跳过 - 注意：
XCLAIM不会自动更新 consumer 的 last_delivered_id，所以后续仍要用>继续消费新消息
Redis 服务端重启，Stream 消息会不会丢？
不会丢——前提是启用了 AOF 或 RDB 持久化。Stream 数据和其他 Redis 数据一样，写入即落盘（AOF）或定期快照（RDB）。
- 默认配置下，
appendfsync everysec是安全底线：最多丢 1 秒数据 - 如果用
appendfsync always，性能下降明显，一般不推荐 - 务必禁用
no-appendfsync-on-rewrite，否则 AOF 重写期间可能丢消息 -
XADD命令本身是原子的，即使在 AOF 重写中途崩溃，也不会出现半条消息
消费组偏移量（last_delivered_id）怎么持久化？
它不单独存，而是和整个 Stream 键一起被持久化。但有个关键细节：Redis 重启后，last_delivered_id 不会自动恢复到消费组里——它只存在于内存中，靠 XGROUP SETID 手动重置。
- 消费者组创建时用
XGROUP CREATE mystream mygroup $，表示从最新消息开始，$是一个占位符，不是真实 ID - 重启后，必须显式执行
XGROUP SETID mystream mygroup 1710234567890-0，把游标设回上一次确认的 ID 或更早位置 - 如果你没记录这个 ID，只能退回到
0-0或用XPENDING反推最近的活跃 ID - 生产环境建议：每次成功
XACK后，把对应 msg ID 写入一个独立 key（如mygroup:last_ack_id），作为 fallback 依据
最易被忽略的一点：PEL 不是无限长的。它只存未确认消息，但不保证永远可用——如果消费者长期宕机，PEL 可能因内存压力被驱逐（虽然极少见），或者被运维误删。所以幂等性不能只靠 PEL，必须落地到业务逻辑或外部存储。
