Golang中Redis PubSub连接断开重连实现的合理性咨询

1. 修正WaitGroup的误用 #

你当前的WaitGroup设计存在冗余且有风险：主goroutine的wg.Wait()只需要等待第一次Redis连接初始化完成，后续循环里的wg.Add(1)完全没必要——因为主goroutine已经完成了等待，后续的WaitGroup操作不会再影响主流程，反而可能因意外操作导致计数异常。

可以简化这部分逻辑：

var wg sync.WaitGroup
wg.Add(1)
go func() {
    recoverChannel := make(chan error, 1) // 改为带缓冲通道，避免发送阻塞
    for {
        // 尝试初始化连接，修改InitRedisConnection让它返回错误
        if err := redis.InitRedisConnection(); err != nil {
            log.Printf("连接Redis失败，3秒后重试: %v", err)
            time.Sleep(3 * time.Second)
            continue
        }
        // 仅第一次连接完成时通知主goroutine
        if wg.Waiting() > 0 {
            wg.Done()
        }

        // 启动订阅goroutine
        go redis.SubscribeRedisChannel("channel", recoverChannel)

        // 等待订阅出错信号
        err := <-recoverChannel
        log.Printf("订阅出错，准备重连: %v", err)

        // 重连前关闭旧连接，避免TCP资源泄漏
        redis.CloseRedisConnection()
    }
}()

wg.Wait()
// 启动HTTP服务...

2. 在订阅函数内部捕获Panic #

不要让Panic扩散到外部goroutine，应该在SubscribeRedisChannel内部用recover()处理异常，再将错误发送到通道：

func SubscribeRedisChannel(channel string, errChan chan<- error) {
    defer func() {
        if r := recover(); r != nil {
            // 将panic转为可处理的错误发送
            errChan <- fmt.Errorf("订阅触发panic: %v", r)
        }
    }()

    // 原有订阅逻辑示例
    sub := redis.GetClient()
    pubsub := sub.Subscribe(context.Background(), channel)
    defer pubsub.Close()

    for {
        msg, err := pubsub.Receive(context.Background())
        if err != nil {
            // 非panic的错误也直接发送到通道
            errChan <- fmt.Errorf("接收消息失败: %v", err)
            return
        }
        // 处理消息逻辑...
    }
}

3. 完善连接生命周期管理 #

• 强制关闭旧连接：每次重连前必须关闭之前的Redis客户端连接，防止TCP连接泄漏，导致系统句柄耗尽。
• 让InitRedisConnection返回错误：当前的InitRedisConnection没有返回错误，无法感知连接是否真的成功，修改为返回error类型后，能在循环中处理连接失败的重试逻辑。

4. 添加重连延迟 #

当Redis连接或订阅失败时，不要立刻发起重试，添加3-5秒的延迟，避免短时间内大量重试请求压垮Redis服务，同时减少本地CPU消耗。

5. 避免通道阻塞风险 #

将recoverChannel改为带缓冲的通道（比如make(chan error, 1)），防止订阅goroutine在发送错误时因主循环未及时接收而阻塞。

内容的提问来源于stack exchange，提问作者dennbagas