本文详解使用 redigo 库构建健壮 redis pub/sub 客户端的关键实践：通过带标签的循环实现优雅重连、正确释放资源、设置连接超时，并提供可直接运行的生产级示例代码。
在 Go 中使用 redigo 进行 Redis 订阅（Pub/Sub）时，网络抖动、Redis 服务重启或连接中断是常见场景。若不妥善处理，会导致订阅永久失效、 goroutine 泄漏或资源耗尽。惯用且可靠的重连模式并非简单地 continue 循环，而需兼顾连接生命周期管理、错误分类处理和退避策略。
以下是一个经过优化的生产就绪型实现：
package main
import (
"fmt"
"log"
"net"
"time"
"github.com/garyburd/redigo/redis"
)
func subscribeWithReconnect(channel string, addr string) {
const (
dialTimeout = 3 * time.Second
readTimeout = 5 * time.Second
writeTimeout = 5 * time.Second
reconnectDelay = 5 * time.Second
)
for {
log.Println("Attempting Redis connection...")
// 使用 DialTimeout 避免阻塞式 dial 永久挂起
c, err := redis.Dial("tcp", addr,
redis.DialConnectTimeout(dialTimeout),
redis.DialReadTimeout(readTimeout),
redis.DialWriteTimeout(writeTimeout),
)
if err != nil {
log.Printf("Failed to connect to Redis (%s): %v. Retrying in %v...", addr, err, reconnectDelay)
time.Sleep(reconnectDelay)
continue
}
defer c.Close() // 注意：此处 defer 不生效于循环内，下文说明
psc := redis.PubSubConn{Conn: c}
if err := psc.Subscribe(channel); err != nil {
log.Printf("Failed to subscribe to %s: %v", channel, err)
_ = c.Close() // 立即关闭异常连接
time.Sleep(reconnectDelay)
continue
}
receiveLoop:
for {
switch v := psc.Receive().(type) {
case redis.Message:
log.Printf("Received on %s: %s", v.Channel, v.Data)
// ✅ 处理业务逻辑（如反序列化、分发事件等）
case redis.Subscription:
log.Printf("Subscription status: %s %s %d", v.Channel, v.Kind, v.Count)
case error:
log.Printf("Pub/Sub error: %v", v)
// ✅ 关键：必须显式关闭 PubSubConn 及底层连接
_ = psc.Close() // 调用 Close() 会自动关闭底层 Conn
break receiveLoop // 退出内层循环，触发外层重连
default:
log.Printf("Unexpected message type: %T", v)
}
}
}
}
func main() {
// 在独立 goroutine 中运行，避免阻塞主流程
go subscribeWithReconnect("example", "localhost:6379")
// 模拟程序长期运行
select {}
}⚠️ 关键注意事项
- 必须显式调用 psc.Close()：PubSubConn.Close() 不仅清理订阅状态，还会关闭底层 redis.Conn。遗漏此步将导致文件描述符泄漏和连接堆积。
- 禁用 defer c.Close()：因连接在循环内反复创建，defer 会在函数返回时才执行，无法及时释放当次连接。应改用显式 c.Close() 或更推荐的 psc.Close()。
- 始终使用 DialTimeout 等超时选项：防止 Dial 在 DNS 解析失败、防火墙拦截等场景下无限期阻塞。
- 区分错误类型：psc.Receive() 返回的 error 通常表示连接已断开（如 i/o timeout、connection refused、broken pipe），此时应重连；而 Subscribe() 的错误则多为命令层面问题（如权限不足），需单独处理。
- 退避策略进阶建议：生产环境可引入指数退避（如 time.Sleep(time.Second
✅ 总结
惯用的 Redis 订阅重连模式 = 带标签的外层连接循环 + 显式资源清理 + 超时控制 + 清晰的错误分支。它不是“兜底重试”，而是对连接状态机的精确建模。结合 redigo 的 PubSubConn 接口语义，该模式能确保高可用性、可观测性与资源安全性，是构建事件驱动微服务的基础能力。
