Celery 3.1.16未检测到Redis broker断开 运行一段时间后冻结如何解决

大量处于CLOSE_WAIT状态的Redis连接是问题的核心诱因：Redis broker端因网络波动、空闲超时主动断开连接后，Celery 3.1.16版本的底层连接池未正确回收半关闭连接，也不会主动触发重建逻辑，导致worker阻塞在无效socket IO上出现冻结。

配置层调整（无需修改业务代码，优先落地） #

• 在Celery配置文件中新增以下连接相关参数：

  # 开启broker心跳检测，10秒一次检测死连接
  BROKER_HEARTBEAT = 10
  # 心跳检查执行频率
  BROKER_HEARTBEAT_CHECKRATE = 2
  # 禁用broker连接池，每次操作重新获取连接，避免复用死连接
  BROKER_POOL_LIMIT = 0
  # broker连接超时时间，避免无限等待无响应的连接
  BROKER_CONNECTION_TIMEOUT = 4
  # 开启连接自动重试
  BROKER_CONNECTION_RETRY = True
  # 连接重试无上限
  BROKER_CONNECTION_MAX_RETRIES = None
  

• 调整Redis服务端配置，将redis.conf中的timeout参数设置为0或者大于Celery心跳间隔的数值，避免Redis主动断开正常空闲的合法连接。
• 调整TCP keepalive内核参数，有容器权限可以直接在容器内配置，无权限可以在K8s节点或Pod安全上下文配置：

  net.ipv4.tcp_keepalive_time = 300
  net.ipv4.tcp_keepalive_intvl = 30
  net.ipv4.tcp_keepalive_probes = 3
  

依赖版本升级（兼容Python 2.7环境，无业务侵入） #

• 升级Celery到3.1.25版本：该版本是3.1分支的最终稳定版，修复了大量已知的Redis broker连接泄漏、死连接未回收的bug，完全兼容Python 2.7和现有任务代码。
• 升级Python Redis客户端到2.10.6版本：该版本是兼容Python 2.7和Celery 3.1.x的最高稳定版，修复了旧版本客户端的连接回收异常问题。

运行层兜底机制（配合上述方案使用） #

• 启动Celery worker时添加--max-tasks-per-child参数，每个worker进程执行指定数量任务后自动退出重建，自动释放所有旧连接避免累积，示例启动命令：

  celery worker -A <你的应用模块名> --max-tasks-per-child=1000
  

• 配置K8s存活探针自动检测worker状态，无响应时自动重启Pod，替代手动定期重启操作，示例探针配置：

  livenessProbe:
    exec:
      command:
      - /bin/bash
      - -c
      - "celery inspect ping -A <你的应用模块名> -d celery@$HOSTNAME | grep -q pong"
    initialDelaySeconds: 30
    periodSeconds: 60
    failureThreshold: 3
  

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