Redis Stream不是Kafka平替，而是需主动管理ACK、PEL、XTRIM等生命周期的轻量替代方案，因其无协调者、无自动rebalance、无消息自动清理机制。
Redis Stream 不是 Kafka 的“平替”，而是特定场景下的“够用替代”——它能省掉 ZooKeeper、Broker 集群和运维监控体系，但要求你主动管理消息生命周期、ACK 和数据清理。
为什么不能直接照搬 Kafka 的使用习惯？
很多人一上来就建 consumer group、起多个 consumer，结果发现消息不均衡、PEL（Pending Entries List）越积越多、XREADGROUP 返回空却没报错。根本原因在于：Kafka 有 Coordinator 自动做 Rebalance 和 Offset 提交，而 Redis Stream 的消费组完全无状态、无协调者，所有逻辑都得靠你显式控制。
-
XREADGROUP不会自动更新组内游标，必须配合XACK才能推进；漏调XACK就等于消息永远卡在 PEL 里 - 没有自动心跳或超时剔除机制，一个挂掉的
consumer会持续占用 PEL 中的消息，导致其他消费者无法接手 - 消费组创建后，首次读取必须指定起始 ID（如
>或0-0），否则可能重复消费或跳过历史消息
生产者必须注意的三个参数细节
XADD 看似简单，但 ID 生成策略和字段设计直接影响后续回溯与调试效率：
- 用
*自动生成 ID 是最安全的选择，格式为<ms>-<seq>，天然支持按时间排序；手动指定 ID 容易因时钟漂移或并发导致乱序 - 避免把整个 JSON 字符串塞进单个 field（如
data "{...}"），应拆成语义化 key-value 对（如user_id "1001" order_id "ORD-20261020-1"），方便用XCLAIM或脚本做条件过滤 - 如果消息体较大（>1KB），要考虑 Redis 单 key 内存碎片问题；可搭配
MAXLEN ~1000000限制 Stream 长度，防止 OOM
消费者必须自己实现的三件事
Kafka 客户端帮你做了很多事，换成 Redis Stream 后，这些逻辑要落地到你的代码里：
-
ACK 必须显式调用：处理完消息后，立刻执行
XACK mystream mygroup 1712345678901-0；不调 = 消息还在 PEL，下次XREADGROUP还会返回它 -
死信需手动转移：若某条消息反复失败（比如重试 3 次仍异常），要用
XCLAIM把它从 PEL 拿出来，再XADD到另一个死信 Stream（如dlq:my_stream），否则它会一直阻塞该 consumer 的游标 -
离线消息要主动拉取：新 consumer 加入时，别只用
>，应先查XINFO GROUPS mystream看当前last-delivered-id，再决定从哪开始读；否则可能错过上线前的全部消息
数据清理和长期运行的隐患点
Stream 不会自动删旧数据，也不像 Kafka 那样按时间/大小滚动日志。放任不管的结果是内存持续上涨，直到触发 maxmemory 策略被 LRU 清掉——但 Stream 是 LRU 不友好的结构，容易引发抖动。
- 推荐方案：定期执行
XTRIM mystream MAXLEN 1000000（保留最近 100 万条），比MINID更可控 - 不要依赖 AOF/RDB 做“持久化兜底”：AOF 重写时大 Stream 可能阻塞主线程；RDB fork 大内存页也会卡顿
- 监控关键指标必须加：用
XINFO STREAM mystream查length和groups数量；用XINFO GROUPS mystream查每个 group 的pending数和last-delivered-id，及时发现堆积
真正难的不是命令怎么写，而是把 Kafka 里由框架隐式承担的状态管理（offset 提交、rebalance、dead letter、retention）全搬到应用层来写清楚、测完整、监控住。
