我在一个应用程序中运行Celery 3.0.24和Celery-with-redis 3.0，该应用程序使用定期任务轮询json提要，并根据它自动执行任务。
芹菜正确地宣布每1分钟发生一次正当任务。但是，似乎该任务被拾取2-3次，这导致其后面的应用程序重复并重复三次。
问题通常不是一天或一周发生，而是随后开始，尽管停止并重新启动应用程序，但不会消失。
详细信息：
当它运行时，进程（ps aux样式）显示为：
[celeryd@sky04:MainProcess] -active- (worker --config celeryconfig --beat --schedule=/mnt/services/my_app/var/lib/celerybeat --loglevel=INFO --autoreload --app=my_app.queue.tasks --events --queues=my_app)
celerybeat.conf：
[program:celerybeat]
command=/mnt/services/my_app/bin/celery worker --config celeryconfig --beat --schedule=/mnt/services/my_app/var/lib/celerybeat --loglevel=INFO --autoreload --app=my_app.queue.tasks --events --queues=my_app
environment=PYTHONPATH=/mnt/services/my_app/conf
autostart=false
autorestart=true
startsecs=5
startretries=1
stopwaitsecs=300
numprocs=1
stopsignal=TERM
killasgroup=true
stdout_logfile=/mnt/services/my_app/var/log/celerybeat.log
stderr_logfile=/mnt/services/my_app/var/log/celerybeat.err
tasks.py包含此任务：
@periodic_task(
run_every=datetime.timedelta(seconds=60),
name='tasks.my_app_fetch_and_parse_feed',
max_retries=0,
queue='my_app',
options={'queue': 'my_app'},
)
def my_app_fetch_and_parse_feed():
"""
Runs every minute and checks for
matches that need notifications sent.
"""
# some code that's getting run multiple times
pass
任何人都可以给予的任何帮助和提示将不胜感激！我已经解决了所有关于如何修复它的想法。非常感谢你！
与芹菜相关的过程是：
$ ps xuf
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
507 29554 0.0 0.0 12768 4828 pts/4 S+ 2013 0:00 -bash
507 22921 0.0 0.0 12920 5408 pts/0 S 19:22 0:00 -bash
507 25582 0.0 0.0 8584 812 pts/0 R+ 19:41 0:00 \_ ps xuf
507 13968 0.0 0.0 12804 5376 pts/1 S+ Feb04 0:00 -bash
507 7617 0.0 0.1 106536 12284 ? Ss 2013 60:06 python2.7 /mnt/services/my_app/bin/supervisord
507 23894 13.0 0.3 154644 25168 ? Rl 19:29 1:32 \_ [celeryd@sky03:MainProcess] -active- (worker --beat --schedule=/mnt/services/my_app/var/lib/celerybeat --loglevel=INFO --autoreload --app=my_app
507 23901 0.0 0.2 147852 22608 ? S 19:29 0:00 \_ [celerybeat]
507 23902 6.2 0.3 143476 26288 ? S 19:29 0:44 \_ [celeryd@sky03:PoolWorker-2]
507 23903 6.3 0.3 143980 26712 ? S 19:29 0:44 \_ [celeryd@sky03:PoolWorker-3]
或者对于与盒子上的芹菜相关的所有过程的更详细的输出：
$ ps aux | grep celery
APP_TWO 22229 0.0 0.3 164808 26244 ? Sl 2013 2:01 python2.6 /mnt/services/APP_TWO-john/bin/celeryd --loglevel=INFO --autoreload -A APP_TWO.queue.tasks -E
APP_TWO 22266 0.0 0.3 153868 25536 ? S 2013 2:08 python2.6 /mnt/services/APP_TWO-john/bin/celeryd --loglevel=INFO --autoreload -A APP_TWO.queue.tasks -E
APP_TWO 22267 0.0 0.3 153312 24112 ? S 2013 2:05 python2.6 /mnt/services/APP_TWO-john/bin/celeryd --loglevel=INFO --autoreload -A APP_TWO.queue.tasks -E
APP_TWO 22000 0.0 0.0 3820 528 pts/2 S+ 2013 0:01 tail -n 30 -F var/log/celeryd.err
APP_FOUR 22055 0.0 0.0 3820 516 pts/3 S+ 2013 0:00 tail -F var/log/celeryd.err
APP_TWO 12190 0.0 0.3 159004 24316 ? Sl Jan06 0:53 python2.6 /mnt/services/APP_TWO/bin/celeryd --loglevel=INFO --autoreload -A APP_TWO.queue.tasks -E -Q APP_TWO
APP_TWO 12212 0.0 0.2 140736 20252 ? S Jan06 0:39 python2.6 /mnt/services/APP_TWO/bin/celeryd --loglevel=INFO --autoreload -A APP_TWO.queue.tasks -E -Q APP_TWO
APP_TWO 12215 0.0 0.2 140760 20260 ? S Jan06 0:48 python2.6 /mnt/services/APP_TWO/bin/celeryd --loglevel=INFO --autoreload -A APP_TWO.queue.tasks -E -Q APP_TWO
flume-ng 27903 0.0 0.0 3816 524 ? S Jan24 0:00 tail -F /mnt/services/APP_TWO/var/log/celeryd.err
flume-ng 27904 0.0 0.0 3816 524 ? S Jan24 0:00 tail -F /mnt/services/APP_FOUR/var/log/celeryd.log
flume-ng 27927 0.0 0.0 3820 576 ? S Jan24 0:00 tail -F /mnt/services/APP_THREE/var/log/celeryd.err
flume-ng 27945 0.0 0.0 3812 564 ? S Jan24 0:00 tail -F /mnt/services/APP_THREE/var/log/celerybeat.err
flume-ng 27951 0.0 0.0 3812 564 ? S Jan24 0:00 tail -F /mnt/services/MY_APP/var/log/celeryd.log
flume-ng 27967 0.0 0.0 3816 580 ? S Jan24 0:00 tail -F /mnt/services/APP_THREE/var/log/celeryd.log
flume-ng 27969 0.0 0.0 3820 528 ? S Jan24 0:00 tail -F /mnt/services/MY_APP/var/log/celerybeat.log
flume-ng 27970 0.0 0.0 3820 528 ? S Jan24 0:00 tail -F /mnt/services/APP_FOUR/var/log/celeryd.err
flume-ng 27974 0.0 0.0 3816 568 ? S Jan24 0:00 tail -F /mnt/services/APP_THREE/var/log/celerybeat.log
flume-ng 27977 0.0 0.0 3812 564 ? S Jan24 0:00 tail -F /mnt/services/MY_APP/var/log/celeryd.err
flume-ng 28050 0.0 0.0 3816 520 ? S Jan24 0:00 tail -F /mnt/services/APP_TWO/var/log/celeryd.log
508 9256 0.0 0.3 197348 29076 ? Sl Feb08 0:04 python2.7 /mnt/services/APP_THREE/bin/celery worker -B -Q APP_THREE --loglevel=INFO --autoreload -A APP_THREE.queue.tasks -E
508 9264 0.0 0.3 200584 27656 ? S Feb08 0:00 python2.7 /mnt/services/APP_THREE/bin/celery worker -B -Q APP_THREE --loglevel=INFO --autoreload -A APP_THREE.queue.tasks -E
508 9265 0.0 0.3 202092 28060 ? S Feb08 0:48 python2.7 /mnt/services/APP_THREE/bin/celery worker -B -Q APP_THREE --loglevel=INFO --autoreload -A APP_THREE.queue.tasks -E
508 9266 0.0 0.3 206420 29880 ? S Feb08 0:46 python2.7 /mnt/services/APP_THREE/bin/celery worker -B -Q APP_THREE --loglevel=INFO --autoreload -A APP_THREE.queue.tasks -E
APP_FOUR 14512 0.0 0.3 153144 23736 ? Sl 18:23 0:00 python2.7 /mnt/services/APP_FOUR/bin/celeryd --loglevel=INFO --autoreload -A APP_FOUR.queue.tasks -E -Q APP_FOUR
APP_FOUR 14545 0.0 0.2 136212 19868 ? S 18:23 0:00 python2.7 /mnt/services/APP_FOUR/bin/celeryd --loglevel=INFO --autoreload -A APP_FOUR.queue.tasks -E -Q APP_FOUR
APP_FOUR 14547 0.0 0.2 136232 19872 ? S 18:23 0:00 python2.7 /mnt/services/APP_FOUR/bin/celeryd --loglevel=INFO --autoreload -A APP_FOUR.queue.tasks -E -Q APP_FOUR
507 23894 14.6 0.3 154644 25168 ? Sl 19:29 2:08 [celeryd@sky03:MainProcess] -active- (worker --beat --schedule=/mnt/services/MY_APP/var/lib/celerybeat --loglevel=INFO --autoreload --app=MY_APP.queue.tasks --events --queues=MY_APP)
507 23901 0.0 0.2 147852 22640 ? S 19:29 0:00 [celerybeat]
507 23902 6.1 0.3 143500 26312 ? S 19:29 0:53 [celeryd@sky03:PoolWorker-2]
507 23903 6.1 0.3 143660 26452 ? S 19:29 0:54 [celeryd@sky03:PoolWorker-3]
507 25859 0.0 0.0 6040 676 pts/0 S+ 19:43 0:00 grep celery
答案 0 :(得分：2)
与Celery IRC（ionelmc）中可爱的人交谈时，可能会发生这种情况，因为我的机器上正在运行多个节拍实例。
你可以看到你'ps aux |的时候在盒子上的grep celery'，my_app正在使用beat，APP_THREE也是如此。我应该可以通过关闭其中一个来解决它。
答案 1 :(得分：0)
此外，可能一直是--schedule参数没有设置在一个节拍的实例上，而是在另一个节点上。或者，可能是两者上的redis队列都在使用db 0.我还没有明确找到修复程序，但是--schedule参数当前正在运行。
答案 2 :(得分：0)
我对 beat 有同样的问题，事实证明我的数据库文件权限不正确。
我将docker-compose安装与插入的本地数据库文件一起用作卷。
我在本地和 docker 中运行来自不同用户（自定义本地和 docker 中的root）的节拍。
似乎一旦我第一次在本地运行， docker 安装就无法读取数据库，因为它是由本地用户拥有的。