redis stream 消息不会丢，靠的是rdb快照、aof日志和stream自身maxlen控制三层持久化协同；消息id带时间戳保证有序，pel机制确保未ack消息可被重新分配，last_delivered_id随持久化自动恢复。
Redis Stream 消息为什么不会丢？靠的是三层持久化机制
Redis Stream 的消息默认写入内存，但不是“只存在内存里”。它通过 RDB 快照、AOF 日志、Stream 自身的 MAXLEN 控制三者协同，实现不同粒度的持久保障。
常见误解是“开了 AOF 就绝对不丢”，其实不然：如果 appendfsync 设为 everysec（默认），最多可能丢失 1 秒数据；设为 always 才能保证每条 XADD 都落盘，但性能下降明显。
- RDB：定期全量备份，适合灾难恢复，但无法保证最近几秒数据
- AOF：记录所有写命令，
appendfsync always可做到强一致，但吞吐受限 - Stream 内部：消息 ID 带毫秒时间戳，天然有序；
XTRIM或XADD ... MAXLEN控制长度，避免无限增长撑爆内存
消费者组重启后怎么接着消费？关键看 last_delivered_id
消费者组的状态（比如每个消费者最后处理到哪条消息）是自动保存在 Redis 内部的，不依赖外部存储。这个偏移量叫 last_delivered_id，对应每个消费组在 stream 上的消费位点。
如果你删了 stream 或清空了 Redis，这个状态就没了；但如果只是 Redis 重启且启用了持久化，last_delivered_id 会随 AOF/RDB 一起恢复。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
XGROUP SETID可手动重置消费起点，比如从头开始：XGROUP SETID mystream mygroup 0-0 - 用
XINFO GROUPS查看当前所有消费组的last-delivered-id和pending数量 - 注意：消费者名称（如
consumer1）只是逻辑标识，不持久化；真正持久的是组 + stream + offset 三元组
消息被读取但没 ACK，Redis 怎么防止丢失？Pending List 是核心
调用 XREADGROUP 后，消息不会立刻从 stream 删除，而是先标记为“待确认”，进入该消费组的 Pending Entries List（PEL）。只有收到 XACK，才会真正移出 PEL。
这意味着：消费者崩溃、网络中断、或业务处理失败没发 XACK，消息依然卡在 PEL 里，其他同组消费者可通过 XPENDING 发现，并用 XCLAIM 主动接管。
-
XPENDING mystream mygroup查看所有未确认消息及 idle 时间 -
XCLAIM mystream mygroup new_consumer 5000 message_id把 idle 超过 5 秒的消息转给new_consumer - PEL 中的消息也受 AOF 记录，所以即使 Redis 重启，未 ACK 的消息仍可被重新分配
实际部署中最容易被忽略的两个点
一是 XADD 不加 MAXLEN —— stream 会无限追加，内存持续上涨，最终 OOM；二是消费者代码里漏掉 XACK，或者 XACK 放在 try/catch 外层，导致异常时根本没机会确认。
这两个问题不会立刻报错，但会在高负载或故障时集中暴露：前者压垮 Redis，后者让 PEL 积压成山，新消费者启动后要花大量时间处理积压，甚至触发超时熔断。
