必须用 pipeline 批量写入弹幕，因单条命令网络 rtt 瓶颈导致延迟暴增；集群下需手动路由到对应 slot 节点执行 pipeline，并严格控制批大小、校验每条命令错误、避免混用读写命令。
直接用 client.Pipeline() 发弹幕批量写入，不控制批大小、不校验每个 cmd.Err()、不按 slot 分节点，在集群环境下必然失败——这不是性能问题，是根本发不出去。
为什么弹幕场景必须用 Pipeline 而不是单条 SET
弹幕写入本质是高频、独立、无依赖的字符串追加（如 LPUSH chat:room:1001 "uid233:hello"），每秒几百到几千条。单条命令在跨机房或高延迟网络下，RTT 成为最大瓶颈：1000 条弹幕 ≈ 1000 次 TCP 往返，实测延迟从 2ms 暴涨至 800ms+。Pipeline 把这 1000 次请求压成 1 次发送，服务端顺序执行后一次性回包，网络开销归零，QPS 稳定提升 3–5 倍。
- 本地回环（
127.0.0.1）下，10 条以内命令收益几乎为零，别硬套 - 弹幕 key 设计必须带 hash tag，例如
chat:{room:1001}:messages，确保同房间所有弹幕落在同一 slot - 不要用
INCR或GET混在弹幕写入 pipeline 里——读写混用无法利用中间状态，还可能触发CROSSSLOT错误
怎么写一个真正可用的弹幕批量写入函数
关键不在“塞命令”，而在“控节奏 + 查错误 + 容灾”。以下逻辑已在线上百万级弹幕服务中验证：
- 每批严格控制在
100–500条之间：太少起不到合并效果；超过 500 容易触发 Redis 的proto-max-bulk-len限制（默认 512MB，但实际建议单批总 payload - 必须用同一个
context.Context，且超时设为500ms—— 太短导致整批中断，太长拖慢故障恢复 - 调用
pipe.Exec(ctx)后，**必须遍历每个cmd实例调.Err()**：比如某条LPUSH因 key 被READONLY拒绝，其余 499 条仍会成功，只靠Exec()的 error 根本发现不了 - 示例片段（简化版）：
pip := rdb.Pipeline() for _, msg := range msgs { pip.LPush(ctx, "chat:{room:"+roomID+"}:messages", msg) } _, err := pip.Exec(ctx) if err != nil { // 处理连接断开、超时等底层错误 return err } for i, cmd := range pip.Cmds() { if cmd.Err() != nil { // 记录第 i 条失败，可丢弃或降级走 fallback 队列 log.Warn("msg failed", "idx", i, "err", cmd.Err()) } }
Redis Cluster 下 pipeline 必须绕过 client.Pipeline()
clusterClient.Pipeline() 在 go-redis/v9 中是非法操作，直接 panic。弹幕天然按房间分片，必须手动路由：
- 先算 slot：
slot := clusterClient.KeySlot("chat:{room:1001}:messages") - 再找节点：
node := clusterClient.NodeForKey(slot)（注意：该 node 是*redis.Client类型，不是ClusterClient） - 最后在 node 上建 pipeline：
pip := node.Pipeline()—— 此时它退化为单机 pipeline，不再校验 slot - 更稳妥的替代方案：优先用原生命令
rdb.LPush(ctx, key, msgs...)（支持多值），它内部已做 slot 分发，比手撸 pipeline 更稳、更少出错
最容易被忽略的三个崩点
弹幕服务一旦上线就扛流量，这三个点不提前卡死，凌晨两点必告警：
-
大弹幕内容：单条弹幕 value > 10KB，打包进 pipeline 后整包超限，Redis 直接拒收，错误是
ERR Protocol error或静默截断——必须在写入前做长度校验并截断 -
漏掉
Exec()：常见于 defer 或 if 分支中，代码看着完整，但实际命令全在内存里没发出去，缓存预热失败、排行榜为空都源于此 -
复用已执行的 pipe：
pipe.Exec(ctx)后再调一次会 panic，别在 for 循环里复用同一个 pipe 变量
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
