必须用*自动生成id，因其保证严格单调递增以维护消息顺序和消费者组游标推进；手动id易破坏递增性，导致读取错乱、跳过消息或xadd报错，且破坏>语义、pel管理和maxlen裁剪可靠性。

XADD 必须用 * 自动生成 ID，手动指定 ID 极易破坏单调递增性，导致消费者组读取错乱或跳过消息。

为什么不能手写 XADD 的消息 ID

Redis Stream 依赖 ID 的严格单调递增来保证消息顺序和消费者组游标推进。ID 格式为 毫秒时间戳-序号（如 1725461700000-0），同一毫秒内多条消息靠序号区分。

• 手写 ID 如 100-1、200-1 看似递增，但会绕过 Redis 内部时钟校验，XREADGROUP 可能无法正确识别“新消息”
• 若两个客户端并发写入相同手写 ID（哪怕概率低），Redis 会拒绝第二条并报错 ERR The ID specified in XADD is equal or smaller than the target stream top item
• 消费者组创建时指定的起始 ID（如 0-0）和后续 > 语义，都建立在自动生成 ID 的连续性上

XREADGROUP 首次消费必须用 >，不能用 0-0 或 $

消费者组刚创建完，last_delivered_id 是空的。此时若用 XREADGROUP GROUP group1 c1 STREAMS orders 0-0，会从头重放所有历史消息——这通常不是你想要的“新消费者接入”行为。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• > 表示“只读尚未交付给该组的最新消息”，是生产环境唯一安全的首次读取方式
• $ 表示“只读当前已存在的最后一条”，但若期间有新消息写入而该消费者还没开始读，就会漏掉
• 0-0 强制从头读，适合重建状态或调试，但上线后必须删掉

必须定期调用 XACK，否则 PEL 会无限膨胀

每条被 XREADGROUP 读出的消息，会进入该消费者的 pending entries list (PEL)，直到显式 XACK。不确认 → 不释放 → 内存持续增长 → 最终 OOM。

• ACK 必须在业务逻辑**真正处理完成之后**调用，不能放在读取后立刻调用
• 若处理失败，应跳过 XACK，让消息保留在 PEL 中，后续可通过 XPENDING 扫描 + XCLAIM 重新分配
• 不要依赖超时自动清理：Redis 不会自动丢弃 PEL 中的消息，它只等你 ACK 或主动干预

MAXLEN ~ N 是防止内存失控的底线配置

Stream 默认无限追加，不设上限等于把日志当数据库用。线上必须限制长度，否则单个 Stream 占满几十 GB 内存很常见。

• 用 MAXLEN ~ 10000（带波浪线）比 MAXLEN 10000 更高效：前者允许近似裁剪，避免每次插入都精确扫描最老项
• 不要写 MAXLEN 0 —— 这会禁用裁剪，等同于没设
• 如果业务要求保留 7 天消息，建议配合外部定时任务 + XTRIM，而不是仅靠 MAXLEN，因为后者按条数而非时间维度控制

真正容易被忽略的是：消费者崩溃后，它的 PEL 里消息不会自动转移，必须靠监控 XPENDING + 主动 XCLAIM 来兜底。没有这层机制，就谈不上“可靠”。