redis stream 本身不保证“至少一次”，需配合 xreadgroup + xack + pel 实现；xreadgroup 将消息加入 pel 以支持故障恢复，xack 必须在业务完全成功后调用，pel 需主动监控与兜底。
Redis Stream 本身不保证“至少一次”，但配合 xreadgroup + xack + PEL（Pending Entries List）机制，才能实现这一语义。 关键不是 Stream 自身，而是你是否正确使用消费者组和确认流程。
为什么 xreadgroup 是必须的，而不是 xread？
xread 是简单轮询，读完即丢，没有状态记录，宕机就丢消息；xreadgroup 则会把拉取的消息自动加入该 consumer 所属 group 的 PEL —— 这是“至少一次”的物理基础。
- 每个未
xack的消息都会留在 PEL 中，Redis 持久化存储（AOF/RDB 开启前提下） - 同一 group 内多个 consumer 共享 PEL，任意一个能从 PEL 中捡起超时未 ack 的消息
- 如果用
xread，哪怕加了重试逻辑，也无法跨进程/重启恢复待处理消息
xack 必须在业务逻辑真正成功后调用
很多 bug 出在：业务处理失败、抛异常、或还没走到 xack 就崩溃了 —— 此时消息仍卡在 PEL，下次 xreadgroup 会重新分发。这不是缺陷，而是设计意图。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 不要在 try 块开头就
xack，必须等数据库写入、外部 API 调用、幂等校验全部完成后再执行 - 如果业务逻辑耗时长，建议设置合理的 group pending timeout（
GROUP创建时用RETRYCOUNT和TIMEOUT控制），避免 PEL 积压 -
xack返回 1 表示成功，返回 0 表示该 ID 不在当前 group 的 PEL 中（可能已被其他 consumer 处理并 ack，或根本没拉取过）
PEL 不是万能的：它依赖你主动监控和兜底
PEL 只负责“保留未确认消息”，但不会自动帮你发现卡死的 consumer 或长期滞留的消息。不干预的话，消息可能永远停在 PEL 里。
- 定期用
xpending查看 pending 条目数、最老消息 idle 时间、所属 consumer —— 这是运维基本功 - 对 idle 超过阈值（比如 5 分钟）的消息，用
xclaim主动移交到健康 consumer，避免单点故障拖垮整个 group - 注意：
xclaim需要指定目标 consumer 名，且原 consumer 若恢复，不能再操作该消息（否则可能重复消费）
真正容易被忽略的点是：**PEL 的生命周期完全由你控制，Redis 不会替你判断“这条消息是不是真失败了”。它只忠实地保存、分发、等待确认——剩下的，得靠你的监控、超时策略和幂等设计来闭环。**
