弹幕分发必须用Pipeline而非单条LPUSH，因高并发下RTT成瓶颈，1000条弹幕单发延迟可达800ms+，Pipeline压缩为1次往返；但Redis Cluster中clusterClient.Pipeline()被go-redis/v9禁止panic，须手动计算slot、路由到对应节点后在其*redis.Client上调用Pipeline()，且key必须含hash tag（如{room:1001}）确保同房间弹幕落同一槽。
弹幕分发必须用 Pipeline，单条命令在高并发下会因 RTT 瓶颈导致延迟暴涨，集群环境下不手动路由到 slot 节点则根本发不出去。
为什么弹幕场景非得用 Pipeline 而不是单条 LPUSH
弹幕本质是高频、独立、无依赖的字符串追加操作（如 LPUSH chat:{room:1001}:messages "uid233:hello"），每秒几百到几千条。单条命令在跨机房或公网链路下，RTT 成为最大瓶颈：1000 条弹幕 ≈ 1000 次 TCP 往返，实测延迟从本地 2ms 暴涨至 800ms+。Pipeline 把这 1000 次请求压成 1 次发送，服务端顺序执行后一次性回包，网络开销归零。
但注意：client.Pipeline() 在 Redis Cluster 下直接 panic，go-redis/v9 不允许对 *redis.ClusterClient 调用 Pipeline() —— 这不是配置问题，是 API 层面禁止。
Redis Cluster 下怎么安全地批量写弹幕
集群环境必须绕过 clusterClient.Pipeline()，改用手动 slot 路由：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 用
clusterClient.KeySlot("chat:{room:1001}:messages")计算 key 所属 slot - 再调
clusterClient.NodeForKey(slot)获取对应节点的*redis.Client - 在该节点 client 上调
node.Pipeline()，此时它退化为单机行为，可安全使用 - key 必须带 hash tag（如
chat:{room:1001}:messages），否则同房间弹幕可能散落不同 slot，触发CROSSSLOT错误
怎么写一个真正可用的批量弹幕写入函数
关键不在“塞命令”，而在“控节奏 + 查错误 + 容灾”：
- 每批严格控制在
100–500条之间：太少收益低；超 500 容易触发 Redis 的proto-max-bulk-len限制（建议单批总 payload -
ctx超时设为500ms：太短整批中断，太长拖慢故障恢复 - 调用
pipe.Exec(ctx)后，必须遍历每个cmd实例调cmd.Err()：比如某条LPUSH因 key 被READONLY拒绝，其余 499 条仍会成功，只靠Exec()的 error 根本发现不了 - 严禁混用读写命令：不要在弹幕 pipeline 里夹
INCR或GET，既无法利用中间状态，又可能触发CROSSSLOT
最容易被忽略的三个点
一是 Exec() 返回的 error 只反映连接、超时等底层问题，不代表所有命令都失败；二是每条命令的 cmd.Err() 必须显式检查，漏掉就等于静默丢数据；三是集群下不按 slot 分发、不手动找节点，Pipeline() 就是无效代码——不是慢，是压根不执行。
