Go（基于Redigo的Redis）PubSub循环突发连接断开问题

可能的诱因排查 #

• Redis版本兼容性：从Redis 4升级到7，PubSub底层连接机制存在变化，比如Redis 7默认启用了新的连接优化、超时策略，可能和你的客户端配置不匹配。
• 网络环境差异：DigitalOcean与AWS的网络链路逻辑不同，中间防火墙、负载均衡等设备可能会主动断开空闲连接，即便调低IdleTimeout，也可能因网络侧超时设置更短导致连接被切断。
• 客户端配置变更：升级Go版本和Redis客户端库后，连接池默认参数（如最大空闲连接数、连接存活时长）可能发生变化，未适配新环境。

具体修复建议 #

1. 添加自动重连逻辑
   当前Receive循环没有处理连接断开后的重连机制，一旦出现EOF错误就会直接panic退出。可以在循环中捕获错误，实现指数退避重连：

   var retryCount int
   for {
       msg, err := sub.Receive()
       if err != nil {
           log.Printf("PubSub接收错误: %v，尝试重连...", err)
           // 指数退避，避免频繁重试
           sleepDur := time.Duration(math.Pow(2, float64(retryCount))) * time.Second
           time.Sleep(sleepDur)
           retryCount++
           if retryCount > 5 {
               retryCount = 5
           }
           // 重新建立订阅连接
           sub = redisClient.Subscribe(ctx, channel)
           continue
       }
       retryCount = 0
       // 消息处理逻辑
       switch v := msg.(type) {
       case *redis.Message:
           // 业务处理代码
       case *redis.Subscription:
           log.Printf("订阅状态: %s，频道: %s", v.Kind, v.Channel)
       default:
           log.Printf("未知消息类型: %T", v)
       }
   }
   

2. 适配Redis 7的连接参数

   • 显式配置ReadTimeout和WriteTimeout，避免Redis侧超时导致连接断开：

     opts := redis.Options{
         Addr:         "你的Redis地址",
         IdleTimeout:  30 * time.Second,
         ReadTimeout:  10 * time.Second,
         WriteTimeout: 10 * time.Second,
         // 其他自定义配置
     }
     

   • 同步调整TCP保活参数，匹配Redis 7的tcp-keepalive默认值（300秒）：

     opts.Dialer = &net.Dialer{
         KeepAlive: 60 * time.Second,
     }
     

3. 排查网络侧超时规则

   • 检查DigitalOcean Redis实例的防火墙、安全组规则，确认没有主动断开空闲连接的策略。
   • 使用telnet或nc工具模拟空闲连接，测试连接是否会被提前断开。

4. 防止协程Panic扩散
   在Receive循环外层添加recover()，避免单个PubSub协程panic影响整个服务：

   go func() {
       defer func() {
           if r := recover(); r != nil {
               log.Printf("PubSub协程panic已恢复: %v", r)
               // 可在此触发告警或重新启动协程
           }
       }()
       // 你的Receive循环逻辑
   }()
   

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