consumergroup必须显式创建，否则xreadgroup报错nogroup；xgroup create支持幂等性，$表示从最新消息开始，mkstream可自动创建stream，group间完全隔离且需全局唯一。
ConsumerGroup必须显式创建，否则XREADGROUP直接报错
Redis Stream本身不自动创建ConsumerGroup，XREADGROUP第一次调用时如果Group不存在，会返回(error) NOGROUP No such key or consumer group。这不是权限或连接问题，是设计如此。
实操建议：
- 用
XGROUP CREATE提前建好Group，例如：XGROUP CREATE mystream mygroup $ MKSTREAM（$表示从最新消息开始，MKSTREAM会顺带创建Stream） - 不要依赖客户端库“自动创建”逻辑——多数库（如redis-py）根本不做这层封装
- 多个服务实例启动时并发创建同一Group？Redis 6.2+支持
XGROUP CREATE幂等性，重复执行无副作用；旧版本需加分布式锁或预检XINFO GROUPS
不同ConsumerGroup之间完全隔离，消息不会互相干扰
这是Stream广播的核心机制：每个ConsumerGroup维护独立的last_delivered_id和消费者列表。A组读了某条消息，B组仍能从头读它，互不影响。
注意点：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Group名必须全局唯一，重名会导致后创建的覆盖前一个的状态（尤其是
last_delivered_id） - 如果想让多个Worker协同处理同一批任务（非广播），才用同一个Group；广播场景下，每个下游系统应配专属Group，比如
payment_group、notification_group -
XACK只影响本Group内该消费者的pending状态，对其他Group无效——别指望靠ACK同步进度
XREADGROUP的NOACK参数慎用，丢消息风险高
加NOACK会让Redis跳过pending list记录，即读完就当已消费。表面看吞吐高，但一旦客户端崩溃，这条消息彻底丢失，无法重试。
真实场景建议：
- 广播类任务（如发通知、写日志）可接受少量丢失 → 允许
NOACK - 涉及资金、状态变更等强一致性任务 → 必须去掉
NOACK，后续用XCLAIM捞回pending消息 - Consumer崩溃后恢复，要先查
XPENDING再XCLAIM，而不是直接XREADGROUP——否则可能漏掉未ACK的消息
Stream长度无硬限制，但XTRIM策略直接影响广播延迟和内存
Stream默认无限增长，不trim会导致内存持续上涨，且XREADGROUP扫描范围变大，首次拉取变慢。
选trim策略要看业务容忍度：
- 按数量裁剪：
XTRIM mystream MAXLEN 1000—— 适合事件有明确时效性（如实时风控，只关心最近1000条） - 按时间裁剪（Redis 7.0+）：
XTRIM mystream MAXLEN 1000 MINID 1690000000000-0—— 更精准控制TTL - 不trim？除非你监控到位且内存充足；否则上线前务必配好
MAXLEN，别等OOM才想起这事
