我在一个应用程序中运行Celery 3.0.24和带有redis 3.0的Celery，该应用程序使用定期任务轮询json提要，并基于它自动执行任务。
Celery正确地指出，每1分钟就有一项到期任务发生。然而，该任务似乎被提取了2-3次，这导致了它后面的应用程序的重复和重复运行
这个问题通常不会在一天或一周内出现，但会开始出现，尽管停止并重新启动了应用程序，但不会消失。
详细信息：
- 与Supervisor一起运行
- 队列在Redis上(不是RabbitMQ)
运行时，进程(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
在与Celery IRC(ionelmc)中可爱的人们交谈时，这很可能是因为我的机器上运行了不止一个beat实例。
你可以看到，当你在盒子上"ps aux|grep芹菜"时，my_app正在使用beat，app_THREE也是如此。我应该能够通过关闭其中一个来解决它。
http://docs.celeryproject.org/en/latest/reference/celery.bin.worker.html?highlight=#cmdoption-快速工人B
此外，--schedule参数可能没有在beat的一个实例上设置，但在另一个实例中设置了。或者，可能是这两者上的redis队列都在使用db 0。我还没有完全找到修复方法，但--schedule参数one目前正在工作。
我对beat也有同样的问题，结果是我有不正确的beat数据库文件权限。
我使用docker编写安装程序，将插入的本地数据库文件作为卷。
我从不同的用户(在docker中自定义本地和根)运行beat和local以及docker。
似乎在我第一次在本地运行beat时，docker安装无法读取数据库，因为它归本地用户所有。