Django-Celery的任务

在本人使用Django中定义的Celery任务时，有时会出现这样一种情况：

任务代码的逻辑并没有什么问题，但是在生产环境中任务的执行情况未满足预期要求。

这里举一个例子：

@shared_task
def update_all_baseline_metrics():
	app_pks = ALL_APP_PKS
	for app_pk in app_pks:
		update_baseline_metrics.apply_async(
			args=(app_pk,),
			queue='baseline_queue',
		)

其中，ALL_APP_PKS 在公共静态指标定义：

ALL_APP_PKS = list(App.objects.all().values_list('id', flat=True))

根据上面的代码我们可以得知，该任务理应会遍历所有的App，并异步发起对应数量的子任务。
但是在生产上运行时，不管如何运行，最后总是会少几百个App未执行、任务发起的数量跟实际App数量对不上。

经过分析，出现这种问题的原因就在于上面定义的全局变量。

一般来说，全局变量不是不可以定义，一些写死的字符串类型、字符串映射字典是可以定义为全局变量的，因为它们在任务程序执行过程中并不会有实时获取的变化。

但是上面这个ALL_APP_PKS的定义则不同，我们可以看到它在本质上是对数据库做实时的查询，会根据数据库的变化而变化。

如果仅仅是简单的Python脚本在本地执行，这样定义的全局变量的确能够达到目的。
但是对于在Django中定义的celery任务而言却有另外的说法：

事实上，在tasks中定义的任务只有在部署时会进行Django-celery任务的刷新，task的相关信息是直接”烧录“到机器上的，这其中也就包括在task代码中定义的ALL_APP_PKS，该参数只有在代码部署时获取到对应的主键id序列，部署完毕、任务执行后，该参数是不会再变化的，因为机器将ALL_APP_PKS视为了常量存在，即使后来又有新的app加入也不会变。只有再次部署、刷新，才会再次刷新。

因此，知晓问题后，我们直接修改代码、放弃全局定义即可即可：

@shared_task
def update_all_baseline_metrics():
	app_pks = list(App.objects.all().values_list('id', flat=True))
	for app_pk in app_pks:
		update_baseline_metrics.apply_async(
			args=(app_pk,),
			queue='baseline_queue',
		)