Redis的Stream类型用来做日志实时消费的踩坑手记#

本宫今天要给你们敲敲 Redis Stream 的警钟，别让那堆日志把皇上的后宫搅成马蜂窝。前阵子臣妾半夜被叫去看日志，发现有一堆 stream 已经被消费得像断了根的毛线球，根本找不到头。于是本宫决定把踩过的坑全抖出来，让你们别再跟本宫抢“半夜惊魂”的戏码。

一、Stream 的名字听着很文艺，背后却是个搬运工
Redis Stream 本质上是个有序的日志链表，靠消息 ID 把每条记录串起来。XADD 往里塞消息时默认用时间戳+序列号生成 ID，这玩意儿本身挺好，但若你在高并发下手动设 ID（比如自己拼个 UUID），顺序就可能被搅得稀烂。别以为随意塞 ID 能省事——结果往往是 XREAD 时只能看到一堆“假有序”的碎片。想省心？直接让 Redis 自动生成 ID，省得你跟自己的脑袋过不去。

二、XADD 的坑——别让时间戳把顺序搅乱
有小伙伴在日志里塞了个“timestamp”字段，然后把这条日志的 XADD ID 手动设成 timestamp 的毫秒值。问题是 Redis 自动生成的 ID 是 1609459200000-0 这种格式，直接拿毫秒做 ID 会导致相同毫秒的不同消息被覆盖，或者 ID 超出 64 位范围直接报错。换句话说，别把你的“业务时间”当成 Redis 的 ID，除非你愿意接受“消息失踪”这出悲剧。

三、XREADGROUP 的正确姿势——别把阻塞当成高冷
消费日志最常玩的就是 XREADGROUP BLOCK，但如果你把 BLOCK 时间设得太大，等得花儿都谢了，系统负载却依旧高企。其实 BLOCK 0（一直等）在大流量下会把 consumer 卡死，除非你真的想要“永不退出”。更常见的错误是忘记 XACK，等下次重新启动 consumer，pending list 会爆满，导致 XREADGROUP 不断重复投递，甚至把 stream 当成无限循环的“重播”。本宫亲眼见过有人把 XACK 注释掉了，然后系统日志里全是“重复消费，已被标记为重复”，最后只能手动 XACK 把这些 pending 清掉。

四、Consumer Group 的命名别像“default”这种懒癌
创建 Group 时不少人直接写 XGROUP CREATE mystream mygroup 0，名字用 “default”。等后面跑多个实例时，Group 名冲突、多个 consumer 拿不到消息、甚至报错 “BUSYGROUP Consumer Group name does not exist”。别把 Group 名当成随便的占位符，给它起个有业务含义的前缀，比如 “log-processor-1”。同时记得 XGROUP CREATE 只能在 stream 已存在时创建，否则会报 “NOGROUP”。如果你不确定 stream 是否已经创建，先用 XINFO GROUPS mystream 检查一下，省得半夜被叫去手动补坑。

五、内存与持久化的纠结——XTRIM 的陷阱
Stream 一旦积压，内存会像后宫嫔妃一样争宠。常见的自清理办法是 XTRIM mystream MAXLEN 10000~，注意这里的 ~ 表示近似裁剪，实际删除的消息数量可能比预期多几条。更有意思的是，如果你在 XADD 时不小心用了 MAXLEN 0（不限制），那 stream 会长到把机器的内存吃光。对大流量日志，建议在 XADD 时直接加上 MAXLEN 100000 或使用 XTRIM 定期清理。别等内存报警了才想起来，不然皇上会问“为何皇宫失火？”。

六、重复消费的噩梦——幂等性要自己做好
即使你用了 XACK，仍然可能在极端情况下（网络抖动、Redis 主从切换）出现同一条消息被投递两次。大多数新手会直接在业务里写“if already processed, skip”，但实现方式往往靠一个全局锁或者 Redis 的 SET key msgId EX 60。这样做在高并发下会把锁竞争得像后宫争宠一样惨烈。本宫建议在消费前用 Lua 脚本一次性完成“检查+标记”，保证原子性，省得出现漏单或重复消费的双重打击。

七、上线前的自检——本宫不想半夜被叫醒
① 确认 consumer group 已创建且 ID 对齐（用 XINFO GROUPS mystream 查看）；② 检查 pending entries 是否为 0（XINFO STREAM mystream），若不为 0 说明有未 ACK 的消息