redis stream 消息队列需构建含消费者组、自动进度管理与ack确认的闭环流程：先用xgroup create创建组，再以xreadgroup读取新消息，处理后必须xack确认，否则消息滞留pending；框架默认不支持，须自研常驻进程并做好异常兜底。
Redis Stream 实现消息队列消费，核心不是“把消息取出来就完事”，而是构建一个带消费者组、自动进度管理、失败可追溯的闭环流程。它比 List 或 Pub/Sub 更可靠，关键在于用对命令、管住状态、守住 ACK。
必须先建好消费者组
Stream 本身只是日志，不自带消费逻辑。要让多个消费者协作且不重复消费，得显式创建消费者组：
- 首次运行时执行：
XGROUP CREATE stream_name group_name 0-0（从头开始）或$（只消费新消息） - 确保 group 存在再启动消费者，否则
XREADGROUP会报错 - 推荐加
MKSTREAM参数：如XADD stream_name MKSTREAM * field value，避免因 stream 不存在导致入队失败
消费者要用 XREADGROUP + > 拉新消息
不能用 XREAD，那只是单点读取；真正生产级消费必须走消费者组模式：
- 标准拉取命令：
XREADGROUP GROUP group_name consumer_name COUNT 10 BLOCK 2000 STREAMS stream_name > -
>表示只读尚未分配给任何消费者的“新消息”，这是实现负载均衡的基础 -
BLOCK避免空轮询，COUNT控制批量大小，平衡吞吐与延迟 - 每次拉取后，Redis 自动把消息标记为“待确认（Pending）”，归属到该 consumer 名下
处理完必须手动 XACK，否则消息永远卡住
Stream 不会自动认为“读了=处理完了”。没 XACK，消息就一直留在 Pending 列表里，可能被重新分发或积压：
- 业务逻辑成功后，立即调用：
XACK stream_name group_name message_id - 务必放在 try 块末尾，或用 finally 保证执行；若处理出错，不要 ACK，让系统后续重试或人工干预
- 可用
XPENDING stream_name group_name查看卡住的消息、所属 consumer、停留时间，便于监控和故障排查
常驻进程要自己写，别依赖框架默认队列命令
ThinkPHP、Laravel、Spring Boot 等框架的原生队列驱动默认只支持 List 或 Sorted Set，不支持 Stream 消费者组机制：
- 需单独开发常驻脚本（如 PHP 的
php think stream:consume或 Java 的 Spring Boot CommandLineRunner） - 进程需具备异常兜底：捕获所有未处理异常，记录日志，但不退出，避免整条消费链中断
- 建议搭配进程管理工具（如 Supervisor、systemd）确保崩溃后自动重启
