在使用Redigo客户端进行Redis管道操作时，仅调用c.Flush()不能保证所有已发送命令被服务端处理完毕，必须配合c.Receive()逐条读取响应，否则部分命令可能丢失或未持久化。
在使用redigo客户端进行redis管道操作时，仅调用`c.flush()`不能保证所有已发送命令被服务端处理完毕，必须配合`c.receive()`逐条读取响应，否则部分命令可能丢失或未持久化。
在Redis客户端编程中，Conn.Send() + Conn.Flush()构成典型的管道（pipeline）异步写入模式：Send()将命令序列化后写入本地缓冲区，Flush()则立即将缓冲区内容一次性发往Redis服务器。但关键点在于：Flush()仅负责“发出”，不等待、不校验服务端响应。若程序在Flush()后直接退出（如main()函数结束），而未消费服务端返回的响应，Go运行时可能提前终止连接，导致部分响应丢失——更严重的是，Redis虽已接收并执行命令，但客户端因未Receive()而无法确认结果，且连接关闭时未完成的响应可能被内核丢弃或截断，最终表现为数据写入不全（如预期10万条，实际仅96932条）。
正确做法是：每发送一批命令后，必须显式调用对应次数的c.Receive()来同步获取响应。这不仅确保命令执行成功（可检查返回错误），也强制客户端读取完服务端应答，避免连接异常关闭引发的数据不一致。
以下为修正后的推荐写法（含错误处理与结构优化）：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
func main() {
// ... 初始化连接池等
pool := createPool(*redis_server, *redis_pass)
defer pool.Close()
c := pool.Get()
defer c.Close() // 确保最终释放连接
var i int64
st := tickSec()
// 步骤1：批量发送所有ZADD命令（无网络I/O）
for i = 0; i < *total; i++ {
r := time.Now().Unix() - rand.Int63n(60*60*24*31*12)
score, _ := strconv.Atoi(time.Unix(r, 0).Format("2006010215"))
id := utee.PlainMd5(uuid.NewUUID().String())
if err := c.Send("ZADD", "app_a_5512", score, id); err != nil {
log.Fatalf("Send ZADD failed: %v", err)
}
}
// 步骤2：一次性刷新所有待发命令到Redis
if err := c.Flush(); err != nil {
log.Fatalf("Flush failed: %v", err)
}
// 步骤3：严格匹配次数，逐条接收响应（关键！）
for i = 0; i < *total; i++ {
reply, err := c.Receive()
if err != nil {
log.Fatalf("Receive response %d failed: %v", i, err)
}
// 可选：校验reply是否为整数（ZADD返回插入数量，通常为1）
// if _, ok := reply.(int64); !ok { ... }
}
log.Printf("Successfully inserted %d records in %.2f seconds", *total, time.Since(st).Seconds())
}注意事项：
- ❌ 避免在循环内频繁
Flush()+Receive()（如每10000条一次），会显著降低吞吐量；应采用“全量发送→单次Flush→全量Receive”模式最大化管道效率。 - ✅ 始终检查
Send/Flush/Receive的返回错误，Receive()失败往往意味着网络中断或Redis异常，需中断流程。 - ⚠️
c.Close()在Redigo中具备“兜底读取”行为（自动丢弃剩余响应），但这属于实现细节，不可依赖；显式Receive()才是符合协议规范、可移植的正确实践。 - ? 若需更高性能，可考虑分批次（如每次5000条）发送+接收，平衡内存占用与响应延迟。
总结：Flush()不是“提交事务”的终点，而是“发起请求”的起点；真正的完成信号来自对等的Receive()调用。理解并遵循这一请求-响应配对原则，是保障Redis管道数据完整性的核心。
