blocks|key|4468853|text|异步任务可以使用Celery在Python中完成。您可以简单地将任务推送到芹菜队列中，任务将以异步方式执行。然后，您可以从结果页面执行一些轮询，以检查是否已完成。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4468854|其他选择可以是像Tornado这样的东西。|4468855|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/celery/celery|1|http://www.tornadoweb.org/en/stable/^0|8|6|0|0|8|7|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

Asynchronous tasks can be accomplished in Python using <a href="https://github.com/celery/celery" rel="noreferrer">Celery</a>. You can simply push the task to Celery queue and the task will be performed in an asynchronous way. You can then do some polling from the result page to check if it is completed.

Other alternative can be something like <a href="http://www.tornadoweb.org/en/stable/" rel="noreferrer">Tornado</a>.

blocks|key|4468917|text|这与同步请求的过程相同。您将使用应该返回JsonResponse的View。“棘手”的部分是在客户端，在那里你必须对视图进行异步调用。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4468918|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.djangoproject.com/en/1.8/ref/request-response/#jsonresponse-objects^0|X|4|K|C|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@$9|Q|A|R|1|S]]|E|$]]|$1|F|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]]]

It's the same process that a synchronous request. You will use a <code>View</code> that should return a <a href="https://docs.djangoproject.com/en/1.8/ref/request-response/#jsonresponse-objects" rel="nofollow">JsonResponse</a>. The 'tricky' part is on the client side, where you have to make the async call to the view.

blocks|key|4469307|text|另一种策略是编写一个线程类，它启动您编写的自定义管理命令，使其表现为工作线程。这可能比使用芹菜之类的东西要轻一点，当然也有优点和缺点。在应用程序启动期间，我还使用了这种技术来对迁移生成/应用程序进行排序/自动化(因为它位于管道中)。然后，我的gunicorn启动脚本根据需要在pre_exec()或when_ready()等中启动这些线程，然后在on_exit()中停止它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4469308|#+Description:+Asychronous+Worker+Threading+via+Django+Management+Commands
#+Lets+you+run+an+arbitrary+Django+management+command,+either+a+pre-baked+one+like+migrate,
#+or+a+custom+one+that+you've+created,+as+a+worker+thread,+that+can+spin+forever,+or+not.
#+You+can+use+this+to+take+care+of+maintenance+tasks+at+start-time,+like+db+migration,
#+db+flushing,+etc,+or+to+run+long-running+asynchronous+tasks.++
#+I+sometimes+find+this+to+be+a+more+useful+pattern+than+using+something+like+django-celery,
#+as+I+can+debug/use+the+commands+I+write+from+the+shell+as+well,+for+administrative+purposes.

import+json
import+os
import+requests
import+sys
import+time
import+uuid
import+logging
import+threading
import+inspect
import+ctypes

from+django.core.management+import+call_command
from+django.conf+import+settings

class+DjangoWorkerThread(threading.Thread):
++++"""
++++Initializes+a+seperate+thread+for+running+an+arbitrary+Django+management+command.++This+is
++++one+(simple)+way+to+make+asynchronous+worker+threads.++There+exist+richer,+more+complex
++++ways+of+doing+this+in+Django+as+well+(django-cerlery).

++++The+advantage+of+this+pattern+is+that+you+can+run+the+worker+from+the+command+line+as+well,
++++via+manage.py,+for+the+sake+of+rapid+development,+easy+testing,+debugging,+management,+etc.

++++:param+commandname:+name+of+a+properly+created+Django+management+command,+which+exists
++++++++inside+the+app/management/commands+folder+in+one+of+the+apps+in+your+project.

++++:param+arguments:+string+containing+command+line+arguments+formatted+like+you+would
++++++++when+calling+the+management+command+via+manage.py+in+a+shell

++++:param+restartwait:+integer+seconds+to+wait+before+restarting+worker+if+it+dies,
++++++++or+if+a+once-through+command,+acts+as+a+thread-loop+delay+timer
++++"""

++++def+__init__(self,+commandname,arguments="",restartwait=10,logger=""):
++++++++super(DjangoWorkerThread,+self).__init__()
++++++++self.commandname+=+commandname
++++++++self.arguments+=+arguments
++++++++self.restartwait+=+restartwait
++++++++self.name+=+commandname
++++++++self.event+=+threading.Event()
++++++++if+logger:
++++++++++++self.l+=+logger
++++++++else:
++++++++++++self.l+=+logging.getLogger('root')

++++def+run(self):
++++++++"""
++++++++Start+the+thread.
++++++++"""

++++++++try:
++++++++++++exceptioncount+=+0
++++++++++++exceptionlimit+=+10
++++++++++++while+not+self.event.is_set():
++++++++++++++++try:
++++++++++++++++++++if+self.arguments:
++++++++++++++++++++++++self.l.info('Starting+'+%2B+self.name+%2B+'++worker+thread+with+arguments+'+%2B+self.arguments)
++++++++++++++++++++++++call_command(self.commandname,self.arguments)
++++++++++++++++++++else:
++++++++++++++++++++++++self.l.info('Starting+'+%2B+self.name+%2B+'++worker+thread+with+no+arguments')
++++++++++++++++++++++++call_command(self.commandname)
++++++++++++++++++++self.event.wait(self.restartwait)

++++++++++++++++except+Exception+as+e:
++++++++++++++++++++self.l.error(self.commandname+%2B+'+Unkown+error:+{}'.format(str(e)))
++++++++++++++++++++exceptioncount+%2B=+1
++++++++++++++++++++if+exceptioncount+>+exceptionlimit:
++++++++++++++++++++++++self.l.error(self.commandname+%2B+"+:+"+%2B+self.arguments+%2B+"+:+Exceeded+exception+retry+limit,+aborting.")
++++++++++++++++++++++++self.event.set()
++++++++finally:
++++++++++++self.l.info('Stopping+command:+'+%2B+self.commandname+%2B+"+"+%2B+self.arguments)

++++def+stop(self):
++++++++"""Nice+Stop

++++++++Stop+nicely+by+setting+an+event.
++++++++"""
++++++++self.l.info("Sending+stop+event+to+self...")
++++++++self.event.set()
++++++++#then+make+sure+it's+dead...and+schwack+it+harder+if+not.
++++++++#kill+it+with+fire!++be+mean+to+your+software.++it+will+make+you+write+better+code.
++++++++self.l.info("Sent+stop+event,+checking+to+see+if+thread+died.")
++++++++if+self.isAlive():
++++++++++++self.l.info("Still+not+dead,+telling+self+to+murder+self...")
++++++++++++time.sleep(+0.1+)
++++++++++++os._exit(1)

def+start_worker(command_name,+command_arguments="",+restart_wait=10,logger=""):
++++"""
++++Starts+a+background+worker+thread+running+a+Django+management+command.+

++++:param+str+command_name:+the+name+of+the+Django+management+command+to+run,
++++++++typically+would+be+a+custom+command+implemented+in+yourapp/management/commands,
++++++++but+could+also+be+used+to+automate+standard+Django+management+tasks
++++:param+str+command_arguments:+a+string+containing+the+command+line+arguments+
++++++++to+supply+to+the+management+command,+formatted+as+if+one+were+invoking
++++++++the+command+from+a+shell
++++"""
++++if+logger:
++++++++l+=+logger
++++else:
++++++++l+=+logging.getLogger('root')

++++#+Start+the+thread
++++l.info("Starting+worker:+"%2B+command_name+%2B+"+:+"+%2B+command_arguments+%2B+"+:+"+%2B+str(restart_wait)+)
++++worker+=+DjangoWorkerThread(command_name,command_arguments,+restart_wait,l)
++++worker.start()
++++l.info("Worker+started:+"%2B+command_name+%2B+"+:+"+%2B+command_arguments+%2B+"+:+"+%2B+str(restart_wait)+)

++++#+Return+the+thread+instance
++++return+worker

#<----------------------------------------------------------------------------->

def+stop_worker(worker,logger=""):
++++"""
++++Gracefully+shutsdown+the+worker+thread+

++++:param+threading.Thread+worker:+the+worker+thread+object
++++"""
++++if+logger:
++++++++l+=+logger
++++else:
++++++++l+=+logging.getLogger('root')

++++#+Shutdown+the+thread
++++l.info("Stopping+worker:+"%2B+worker.commandname+%2B+"+:+"+%2B+worker.arguments+%2B+"+:+"+%2B+str(worker.restartwait)+)
++++worker.stop()++++++++
++++worker.join(worker.restartwait)
++++l.info("Worker+stopped:+"%2B+worker.commandname+%2B+"+:+"+%2B+worker.arguments+%2B+"+:+"+%2B+str(worker.restartwait)+)|code-block|syntax|javascript|4469309|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Another strategy is to writing a threading class that starts up custom management commands you author to behave as worker threads. This is perhaps a little lighter weight than working with something like celery, and of course has both advantages and disadvantages. I also used this technique to sequence/automate migration generation/application during application startup (because it lives in a pipeline). My gunicorn startup script then starts these threads in pre_exec() or when_ready(), etc, as appropriate, and then stops them in on_exit().

<pre><code># Description: Asychronous Worker Threading via Django Management Commands
# Lets you run an arbitrary Django management command, either a pre-baked one like migrate,
# or a custom one that you've created, as a worker thread, that can spin forever, or not.
# You can use this to take care of maintenance tasks at start-time, like db migration,
# db flushing, etc, or to run long-running asynchronous tasks. 
# I sometimes find this to be a more useful pattern than using something like django-celery,
# as I can debug/use the commands I write from the shell as well, for administrative purposes.

import json
import os
import requests
import sys
import time
import uuid
import logging
import threading
import inspect
import ctypes

from django.core.management import call_command
from django.conf import settings

class DjangoWorkerThread(threading.Thread):
 """
 Initializes a seperate thread for running an arbitrary Django management command. This is
 one (simple) way to make asynchronous worker threads. There exist richer, more complex
 ways of doing this in Django as well (django-cerlery).

 The advantage of this pattern is that you can run the worker from the command line as well,
 via manage.py, for the sake of rapid development, easy testing, debugging, management, etc.

 :param commandname: name of a properly created Django management command, which exists
 inside the app/management/commands folder in one of the apps in your project.

 :param arguments: string containing command line arguments formatted like you would
 when calling the management command via manage.py in a shell

 :param restartwait: integer seconds to wait before restarting worker if it dies,
 or if a once-through command, acts as a thread-loop delay timer
 """

 def __init__(self, commandname,arguments="",restartwait=10,logger=""):
 super(DjangoWorkerThread, self).__init__()
 self.commandname = commandname
 self.arguments = arguments
 self.restartwait = restartwait
 self.name = commandname
 self.event = threading.Event()
 if logger:
 self.l = logger
 else:
 self.l = logging.getLogger('root')

 def run(self):
 """
 Start the thread.
 """

 try:
 exceptioncount = 0
 exceptionlimit = 10
 while not self.event.is_set():
 try:
 if self.arguments:
 self.l.info('Starting ' + self.name + ' worker thread with arguments ' + self.arguments)
 call_command(self.commandname,self.arguments)
 else:
 self.l.info('Starting ' + self.name + ' worker thread with no arguments')
 call_command(self.commandname)
 self.event.wait(self.restartwait)

 except Exception as e:
 self.l.error(self.commandname + ' Unkown error: {}'.format(str(e)))
 exceptioncount += 1
 if exceptioncount &gt; exceptionlimit:
 self.l.error(self.commandname + " : " + self.arguments + " : Exceeded exception retry limit, aborting.")
 self.event.set()
 finally:
 self.l.info('Stopping command: ' + self.commandname + " " + self.arguments)

 def stop(self):
 """Nice Stop

 Stop nicely by setting an event.
 """
 self.l.info("Sending stop event to self...")
 self.event.set()
 #then make sure it's dead...and schwack it harder if not.
 #kill it with fire! be mean to your software. it will make you write better code.
 self.l.info("Sent stop event, checking to see if thread died.")
 if self.isAlive():
 self.l.info("Still not dead, telling self to murder self...")
 time.sleep( 0.1 )
 os._exit(1)

def start_worker(command_name, command_arguments="", restart_wait=10,logger=""):
 """
 Starts a background worker thread running a Django management command. 

 :param str command_name: the name of the Django management command to run,
 typically would be a custom command implemented in yourapp/management/commands,
 but could also be used to automate standard Django management tasks
 :param str command_arguments: a string containing the command line arguments 
 to supply to the management command, formatted as if one were invoking
 the command from a shell
 """
 if logger:
 l = logger
 else:
 l = logging.getLogger('root')

 # Start the thread
 l.info("Starting worker: "+ command_name + " : " + command_arguments + " : " + str(restart_wait) )
 worker = DjangoWorkerThread(command_name,command_arguments, restart_wait,l)
 worker.start()
 l.info("Worker started: "+ command_name + " : " + command_arguments + " : " + str(restart_wait) )

 # Return the thread instance
 return worker

#&lt;-----------------------------------------------------------------------------&gt;

def stop_worker(worker,logger=""):
 """
 Gracefully shutsdown the worker thread 

 :param threading.Thread worker: the worker thread object
 """
 if logger:
 l = logger
 else:
 l = logging.getLogger('root')

 # Shutdown the thread
 l.info("Stopping worker: "+ worker.commandname + " : " + worker.arguments + " : " + str(worker.restartwait) )
 worker.stop() 
 worker.join(worker.restartwait)
 l.info("Worker stopped: "+ worker.commandname + " : " + worker.arguments + " : " + str(worker.restartwait) )
</code></pre>

I am working in an application where i am doing a huge data processing to generate a completely new set of data which is then finally saved to database. The application is taking a huge time in processing and saving the data to data base. I want to improve the user experience to some extent by redirecting user to result page first and then doing the data saving part in background(may be in the asynchronous way) . My problem is that for displaying the result page i need to have the new set of processed data. Is there any way that i can do so that the data processing and data saving part is done in background and whenever the data processing part is completed(before saving to database) i would get the processed data in result page?.

Python Django Asynchronous Request handling

数据库

Django

Python

我在一个应用程序中工作，我正在做一个巨大的数据处理，以生成一个全新的数据集，然后最终保存到数据库中。应用程序在处理数据和将数据保存到数据库中花费了大量的时间。我想在一定程度上改善用户体验，首先将用户重定向到结果页面，然后在后台进行数据保存部分(可能是以异步方式)。我的问题是，为了显示结果页面，我需要有一组新的处理过的数...

问Python Django异步请求处理
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Python Django异步请求处理EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Python Django异步请求处理
EN