我们来看下面的例子:
我们的用户要求在2011-04-19 20:20发布id为5的文章 所以我想在2011-04-19 20:20创建一个将改变文章状态的任务。
我提出了以下想法:
在这种情况下你有什么建议?什么是性能和扩展的最佳选择。假设每秒执行大约100k个任务。
答案 0 :(得分:4)
我的建议是保持简单的开始,使用CRON每分钟启动一次的管理命令,当这种情况超出您的需求时切换到分布式作业方法。如果你正确地分开你的代码,这不应该是一个很大的改变。
如果你要从一开始就做100k任务,我会选择#1选项,因为你可以使用芹菜来分配许多服务器上的负载。如果选择正常的cronjob设置,则需要在同一台服务器上运行所有任务,这些任务不能很好地扩展。设置RabbitMQ并维护它比设置一个cronjob要多得多,所以尽可能长时间关闭它。
对于选项2:Django-Extentions也有一个类似系统的cronjob作为管理命令实现,所以你不必重新发明轮子,Django-Extentions还有许多其他很棒的工具,你可能还想要使用它们
http://packages.python.org/django-extensions/jobs_scheduling.html
如果你选择#3,请确保使用某些东西来保持守护程序的运行,如果它崩溃,你需要自动启动备份。 http://supervisord.org是个不错的选择。
答案 1 :(得分:1)
我肯定会建议像这样的cron工作。如果您不想处理系统互操作,可以选择django-cron。
答案 2 :(得分:1)
为什么不给出datetime Active字段,默认情况下是now()方法?然后为此模型创建一个Manager,它只返回活动任务,其活动日期将少于现在(如.get_active_only)。 如果您希望将来显示该文章,则只需保存具有未来活动值的对象。 通过这个,你只会搜索有效的文章,并跳过所有上传的文章。