Celery任务未失败却自动重试 间隔1800秒而非默认180秒如何解决

你遇到的1800秒任务重复执行不是Celery主动重试导致，而是RabbitMQ消息可见性超时触发的异常重投递：

• 你在任务上开启了acks_late=True配置，该规则下Celery Worker只会在任务执行完成后才会向RabbitMQ发送消息确认（ACK）
• Celery连接RabbitMQ的默认visibility_timeout参数为1800秒：如果Broker在1800秒内没有收到对应任务的ACK，会判定执行该任务的Worker已经宕机，自动将该任务重新投递到队列，就会触发重复执行，完全匹配你遇到的30分钟间隔
• 你查询到的default_retry_delay是任务主动调用self.retry()接口时的重试延迟，和当前场景无关
• 你收到的AMQP结果后端废弃警告和当前问题无直接关联，但建议后续调整避免版本升级后的兼容问题

按优先级选择即可：

• 1. 调整可见性超时配置
     在Celery配置文件中新增broker_transport_options配置，参数值设置为你业务任务的最长执行时间，建议额外预留20%以上的冗余，比如你的ETL任务最长耗时为2小时，可按如下配置：

  broker_transport_options = {
      'visibility_timeout': 7200
  }
  

• 2. 拆分长耗时任务
     如果单任务耗时普遍超过1小时，建议将ETL流程拆分为多个短耗时的子任务，通过你当前使用的chain等工作流串联执行，避免单任务执行时间过长引发的各类超时问题
• 3. 新增任务幂等校验
     无论是否调整超时配置，都建议给任务增加幂等判断逻辑：执行数据修改前先校验当前处理批次是否已经完成，已经完成的任务直接跳过执行，就算出现异常重投递也不会触发重复写入，从根源避免数据库锁冲突
• 4. （可选）替换废弃的结果后端
     你当前使用的backend='amqp'已经在Celery 4.x版本被废弃，可按警告提示替换为RPC后端：

  backend = 'rpc://'
  

  如果你需要持久化存储任务执行结果，也可以选择Redis、MySQL等作为结果后端

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