Azure容器应用服务中多Celery Beat实例导致任务重复问题排查

问题背景 #

我们的Python项目采用Celery架构处理定时任务，已将Celery Beat和Worker部署在两个独立的Azure容器应用服务中。目前遇到任务重复执行问题：Beat在同一时间（对应日志中的12:20）重复调度任务5次，调度请求来自不同的内部IP。相关日志如下：

2024-05-16T12:20:00.349516119Z [2024-05-16 12:20:00,349: DEBUG/MainProcess] beat: Synchronizing schedule...
2024-05-16T12:20:00.351217950Z [2024-05-16 12:20:00,351: DEBUG/MainProcess] beat: Waking up in 5.00 minutes.
2024-05-16T12:20:00.324680768Z [2024-05-16 12:20:00,324: DEBUG/MainProcess] beat: Synchronizing schedule...
2024-05-16T12:20:00.326966684Z [2024-05-16 12:20:00,326: DEBUG/MainProcess] beat: Waking up in 5.00 minutes.
2024-05-16T12:20:00.333486516Z [2024-05-16 12:20:00,333: DEBUG/MainProcess] beat: Synchronizing schedule...
2024-05-16T12:20:00.336071158Z [2024-05-16 12:20:00,335: DEBUG/MainProcess] beat: Waking up in 5.00 minutes.
2024-05-16T12:20:00.372055059Z [2024-05-16 12:20:00,371: DEBUG/MainProcess] beat: Synchronizing schedule...
2024-05-16T12:20:00.373849705Z [2024-05-16 12:20:00,373: DEBUG/MainProcess] beat: Waking up in 5.00 minutes.
2024-05-16T12:20:00.361135357Z [2024-05-16 12:20:00,360: DEBUG/MainProcess] beat: Synchronizing schedule...
2024-05-16T12:20:00.363359490Z [2024-05-16 12:20:00,363: DEBUG/MainProcess] beat: Waking up in 5.00 minutes.
2024-05-16T12:21:40  No new trace in the past 1 min(s).
2024-05-16T12:22:09.826617525Z 169.254.134.1 - - [16/May/2024 12:22:09] "GET / HTTP/1.1" 200 -
2024-05-16T12:22:09.828852131Z 169.254.141.1 - - [16/May/2024 12:22:09] "GET / HTTP/1.1" 200 -
2024-05-16T12:22:09.828742024Z 169.254.142.1 - - [16/May/2024 12:22:09] "GET / HTTP/1.1" 200 -
2024-05-16T12:22:09.829842011Z 169.254.136.1 - - [16/May/2024 12:22:09] "GET / HTTP/1.1" 200 -
2024-05-16T12:22:09.829044130Z 169.254.143.1 - - [16/May/2024 12:22:09] "GET / HTTP/1.1" 200 -

以下是具体排查方向：

1. 确认Azure容器应用的Beat实例数量 #

• 登录Azure门户，找到Beat所在的容器应用资源，进入缩放页面，查看副本计数。如果副本数设置为5，那就是Azure启动了5个Beat实例，直接导致重复调度。
• 进入监控->实例页面，查看当前运行的容器实例列表，核对实例数量是否与日志中的IP数一致（5个）。

2. 检查Beat容器内部的进程数 #

• 通过Azure容器应用的日志流或进入容器终端，执行命令：

  ps aux | grep celery
  

• 如果输出显示多个celery beat进程，说明容器内部启动了多个Beat实例，问题出在启动脚本或Celery配置；如果只有一个进程，那就是Azure多副本导致的。

3. 验证Beat的启动命令与配置 #

• 检查容器的启动命令，确保是单实例启动：

  celery -A your_project_name beat --loglevel=debug
  

• 确认启动脚本中没有重复调用Beat启动命令，也没有配置自动重启导致的多进程问题。

4. 启用Celery Beat分布式锁（兜底方案） #

• 即使不小心启动了多个Beat，也可以通过分布式锁避免重复调度。如果使用Redis作为消息中间件，配置Beat使用Redis锁：

  # celery配置文件
  CELERY_BEAT_SCHEDULER = 'celerybeatredis.schedulers.RedisScheduler'
  CELERY_REDIS_SCHEDULER_URL = 'redis://your-redis-host:6379/0'
  

• 如果使用数据库（比如Django项目），可以用django_celery_beat的数据库调度器，自动实现分布式锁：

  CELERY_BEAT_SCHEDULER = 'django_celery_beat.schedulers:DatabaseScheduler'
  

5. 增强日志辨识度 #

• 修改Beat启动命令，添加实例hostname到日志中，方便区分不同实例的调度日志：

  celery -A your_project_name beat --loglevel=debug --logformat="%(asctime)s %(hostname)s %(message)s"
  

• 这样日志中会显示每个调度对应的实例hostname，可直接确认调度是否来自不同实例。

内容的提问来源于stack exchange，提问作者Shubh Rocks Goel