Redis Stream 不自动创建消费组，因XREADGROUP需显式XGROUP CREATE，否则报错NOGROUP；XACK须在finally中调用并校验返回值，否则消息滞留PEL；持久化依赖AOF配置，非Stream自身保障。
Redis Stream 本身不自动保证消息不丢失，必须配合 XGROUP 创建消费组、XREADGROUP 拉取、XACK 显式确认，三者缺一不可；漏掉 XACK 或用错 consumer 名，消息就会卡在 PEL 里反复重发或永久滞留。
为什么 XGROUP 必须显式创建，不能靠 XREADGROUP 自动建？
Redis 不会在首次 XREADGROUP 时自动创建消费组——它会直接报错 (error) NOGROUP No such key or consumer group。这意味着你必须提前执行 XGROUP CREATE，否则消费端启动即失败。
-
XGROUP CREATE mystream mygroup $ MKSTREAM中的$表示从最新消息开始消费（跳过历史），MKSTREAM表示如果mystream不存在则自动创建，避免先查后建的竞态 - 若误用
0作为 offset，消费组会从头读所有消息，上线初期可能引发重复处理风暴 - 同一个 stream 可以有多个消费组（如
payment_group和audit_group），互不影响，但每个组必须独立创建
XACK 必须在业务逻辑成功后调用，且要检查返回值
XACK 不是“发了就完事”的操作：它只在消息 ID 确实存在于该消费组的 PEL 中时才返回 1；如果 ID 已被确认、根本不在 PEL 里，或属于别的 consumer，Redis 静默返回 0，不报错也不警告。
- 务必把
XACK放在try/finally（Java/Python）或defer（Go）中，确保无论成功失败都至少尝试一次 - 调用后检查返回值：
if redis.xack(...) == 0应记录告警，说明消息可能已被其他 consumer 处理或 ID 错误 - 别用随机字符串或 PID 当 consumer 名——每次重启都变成新 consumer，PEL 里的消息永远没人认领
PEL 积压不等于消息丢失，但意味着消费链路已断裂
PEL（Pending Entries List）是 Redis Stream 的核心保障机制，但它本身不是兜底方案：它只记录“谁读了、还没确认”，不解决“为什么没确认”。积压超过阈值（比如 >100 条且最老条目空闲超 300 秒），大概率是以下情况之一：
- 消费者进程崩溃且未执行
XACK，消息仍在 PEL 中等待超时（默认 60 分钟）后被XCLAIM接管 - 业务逻辑卡死、无限重试、或异常被吞没（比如 catch 了 Exception 却没 log）
- 网络分区导致 ACK 请求根本没发到 Redis，而客户端以为发成功了
建议用定时任务跑 XPENDING mystream mygroup 扫描，结合 XCLAIM 主动接管超时条目，而不是等它自然超时。
持久化依赖配置，Stream 本身不等于磁盘安全
Stream 消息写入内存后，即使 Redis 崩溃也不会丢失——但这仅限于开启了 AOF 且 appendonly yes、aof-fsync everysec 或更严格策略的前提下。RDB 快照无法保证实时性，两次快照之间写入的消息仍可能丢失。
- 单机模式下，仅靠
XACK无法防止 Redis 进程意外退出导致的未刷盘数据丢失 - 主从架构中，需配置
min-replicas-to-write 1和足够大的repl-backlog-size，避免主节点宕机时从节点没同步到最新消息 - 真正要求强一致的场景（如金融交易），Redis Stream 仍是“至少一次”语义，需上层补幂等或引入 WAL 日志对账
最容易被忽略的一点：XACK 只影响 PEL 状态，和 AOF 写入完全无关。哪怕你每条都正确 XACK 了，如果 Redis 没配 AOF 或 fsync 被禁用，整个 stream 数据在断电后照样归零。
