Redis Pipeline 实战指南：提升 Go 后端性能的利器

---

🔧 什么是 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 条命令