🔧 什么是 Redis Pipeline？
Pipeline（管道）是 Redis 提供的一种批量命令执行机制：
客户端将多个命令一次性发送给 Redis，Redis 顺序执行并批量返回结果，减少网络往返（RTT）开销。
⚠️ 注意：Pipeline ≠ 事务（
MULTI/EXEC）！
- Pipeline：无原子性保证，仅优化网络；多个命令可能部分成功
- Transaction：保证原子性（但不支持回滚），会加 WATCH 锁或阻塞执行
✅ 为什么用 Pipeline？—— 三大核心优势
| 场景 | 无 Pipeline（N 次 RTT） | 用 Pipeline（1 次 RTT） | 提升效果 |
|---|---|---|---|
| 批量写入 100 个用户 | 100 × 网络延迟（如 100×1ms = 100ms） | ~1 × 网络延迟 + 执行时间（≈2ms） | ~50x 性能提升 |
| 高并发写入服务 | 高连接压力，易 TCP 拥塞 | 降低连接负载，请求更紧凑 | ✅ 系统更稳定 |
| 低延迟要求场景（如游戏、支付） | 延迟毛刺明显 | 延迟平稳可控 | ✅ SLA 达标率↑ |
📌 本质：用“本地攒批 + 一次发送”换“高频小包”
💻 Go 实战：go-redis/v9 使用 Pipeline
✅ 场景 1：批量写入用户数据 + 设置过期时间
package main
import (
"context"
"fmt"
"time"
"github.com/redis/go-redis/v9"
)
func bulkAddUsers(ctx context.Context, rdb *redis.Client, users map[string]string) error {
pipe := rdb.Pipeline()
// 构建 pipeline：SET + EXPIRE
for uid, data := range users {
key := "user:" + uid
pipe.Set(ctx, key, data, 0) // 不设 TTL
pipe.Expire(ctx, key, 24*time.Hour) // 单独设过期（或直接 Set(key, val, 24h)）
}
// 执行所有命令（原子发送，非原子执行）
_, err := pipe.Exec(ctx)
return err
}
func main() {
rdb := redis.NewClient(&redis.Options{
Addr: "localhost:6379"})
ctx := context.Background()
users := map[string]string{
"1001": `{"name":"Alice","score":95}`,
"1002": `{"name":"Bob","score":88}`,
"1003": `{"name":"Charlie","score":92}`,
}
if err := bulkAddUsers(ctx, rdb, users); err != nil {
panic(err)
}
fmt.Println("✅ 3 users added via pipeline")
}
✅ 场景 2：批量更新排行榜（ZADD）
func bulkUpdateLeaderboard(ctx context.Context, rdb *redis.Client, scores map[string]int64) error {
pipe := rdb.Pipeline()
for uid, score := range scores {
pipe.ZAdd(ctx, "leaderboard:2025", redis.Z{
Score: float64(score),
Member: uid,
})
}
_, err := pipe.Exec(ctx)
return err
}
🚫 什么时候不该用 Pipeline？
| 禁忌场景 | 原因 | 替代方案 |
|---|---|---|
| 需要原子性/一致性 | Pipeline 中某条命令失败，前面命令可能已生效，无法回滚 | → 改用 MULTI/EXEC 事务（或 Lua 脚本） |
| 命令之间强依赖 | 如 GET key → SET key value+1，中间结果需客户端判断 |
→ 用 Lua 脚本（在 Redis 内部原子执行） |
| 批太大（>10k 命令） | 一次发太多命令：占用 Redis 内存 + 阻塞主线程执行 | → 分片批处理（如每次 1000 条） |
| 实时性要求极高 + 命令极少 | 如仅 1~2 条命令，Pipeline 反而增加封装开销 | → 直接 Set()/Get() 更简洁 |
📌 经验法则：
- 读多写少 + 少量命令 → 不要用 Pipeline
- 批量写/更新 ≥10 条 → 优先考虑 Pipeline
- 业务关键路径需强一致 → Lua + WATCH 锁
📊 性能对比实测
| 方式 | 平均耗时 | P99 耗时 |
|---|---|---|
单条 Set() |
12.3 ms | 25.1 ms |
| Pipeline（batch=1000） | 1.8 ms | 3.2 ms |
| Pipeline（batch=100 × 10 次） | 2.1 ms | 4.0 ms |
🔚 总结：Pipeline 的正确打开方式
| ✅ 推荐用 | ❌ 慎用/禁用 |
|---|---|
| 批量初始化数据（用户、配置、缓存预热） | 涉及资金、状态机变更等核心业务 |
| 后台任务（日志上报、指标统计） | 命令依赖上一条返回结果 |
| 读写分离场景中的“写侧批量” | 单次请求只有 1~3 条命令 |
