Celery与AWS MQ频繁断开连接问题排查求助

核心问题分析 #

从错误日志看，主要是SSL握手超时和连接重试次数耗尽导致Celery Worker/Beat与AWS MQ断开后无法恢复，最终容器失效。以下是针对性的修复方案：

1. 修复Worker启动命令的致命参数 #

当前启动命令中--without-heartbeat直接禁用了Worker的心跳机制，与配置中的CELERY_BROKER_HEARTBEAT=60冲突，导致连接无法维持存活检测，是断开问题的核心原因之一。

修改启动命令：

CMD ["celery", "-A", "server", "worker", "-E", "--autoscale=2,1", "--max-tasks-per-child=1000", "--time-limit=600", "--loglevel=info", "-n", "worker@%h"]

移除--without-heartbeat参数，让Worker启用心跳来维持与MQ的连接。

2. 调整连接重试策略，避免停止重试 #

当前配置CELERY_BROKER_CONNECTION_MAX_RETRIES=10意味着重试10次后就会放弃，导致容器失效。需要改为无限重试：

修改Django settings.py中的配置：

if not IS_LOCAL:
    # RabbitMQ connection settings for better reliability
    CELERY_BROKER_CONNECTION_RETRY_ON_STARTUP = True
    CELERY_BROKER_CONNECTION_RETRY = True
    CELERY_BROKER_CONNECTION_MAX_RETRIES = None  # 改为None，无限重试

同时，调整CELERY_BROKER_TRANSPORT_OPTIONS中的重试参数：

CELERY_BROKER_TRANSPORT_OPTIONS = {
    # ... 其他配置保持不变
    "connection_attempts": 5,  # 每次连接尝试的次数从3改为5
    "retry_on_timeout": True,
    "max_retries": None,  # 与全局配置保持一致
}

3. 优化SSL握手与网络超时配置 #

SSL握手超时是直接触发断开的原因，需要调整相关超时参数，并确保SSL验证正常：

更新SSL相关配置：

CELERY_BROKER_TRANSPORT_OPTIONS = {
    # ... 其他配置保持不变
    # SSL-specific settings
    "ssl_handshake_timeout": 60,  # 从30增大到60，适应AWS MQ可能的网络延迟
    "ssl_timeout": 60,
    # 添加CA证书路径（容器系统默认路径，确保证书完整）
    "ssl_ca_certs": "/etc/ssl/certs/ca-certificates.crt",
    # 确保SSL验证开启
    "ssl_verify": True,
}

4. 优化心跳与连接池配置 #

心跳间隔过长可能导致连接被AWS MQ或中间网络设备主动断开，调整为更合理的数值：

修改心跳配置：

if not IS_LOCAL:
    CELERY_BROKER_HEARTBEAT = 30  # 从60改为30，更频繁检测连接状态
    CELERY_BROKER_TRANSPORT_OPTIONS = {
        # ... 其他配置保持不变
        "heartbeat": 30,  # 与全局心跳配置一致
    }

调整连接池大小：
当前CELERY_BROKER_POOL_LIMIT=None可能导致连接无限制增长，建议根据ECS实例规格设置合理值：

CELERY_BROKER_POOL_LIMIT = 10  # 例如设置为10，避免过多连接压垮MQ

5. AWS MQ层面优化 #

5.1 切换到高可用部署模式 #

当前如果是单实例部署，故障时无冗余，建议改为ACTIVE_STANDBY_MULTI_AZ模式：

resource "aws_mq_broker" "rabbitmq" {
  # ... 其他配置保持不变
  deployment_mode = "ACTIVE_STANDBY_MULTI_AZ"  # 替换原有的SINGLE_INSTANCE
  subnet_ids      = var.private_subnet_ids  # 需要至少两个私有子网
}

5.2 检查MQ实例资源 #

如果MQ实例规格过小（比如t2.micro），可能因资源瓶颈导致连接超时，建议升级到t2.small或更高规格。

5.3 查看MQ日志 #

通过CloudWatch日志组/aws/amazonmq/broker/${var.environment}-project-rabbitmq查看MQ侧的连接日志，确认是否有主动断开或错误信息。

6. ECS网络配置检查 #

• 确保ECS任务与AWS MQ在同一VPC内，且安全组允许ECS所在子网的5671端口访问MQ。
• 检查NAT网关（如果使用）是否有足够带宽，避免网络拥堵导致超时。
• 确认网络ACL没有限制5671端口的入出站流量。

7. Beat配置同步 #

确保Celery Beat使用与Worker完全一致的连接配置，避免Beat调度任务时出现相同的连接问题。如果Beat是单独容器部署，需复用相同的settings.py配置。

8. 启用详细日志排查 #

临时将Celery日志级别改为debug，获取更详细的连接过程信息：

CMD ["celery", "-A", "server", "worker", "-E", "--autoscale=2,1", "--max-tasks-per-child=1000", "--time-limit=600", "--loglevel=debug", "-n", "worker@%h"]

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