python - 来自 Flask 端点的长时间运行的脚本

Question

我一直在努力解决这个问题，希望其他人已经遇到过这个问题并且知道如何解决它:)

我正在尝试构建一个非常简单的 Flask 端点，它只需要调用一个长时间运行的阻塞 php 脚本(想想 while true {...}) .我尝试了几种不同的方法来异步启动脚本，但问题是我的浏览器从未真正收到响应，即使在运行脚本后生成响应的代码已执行。

我试过同时使用 multiprocessing 和 threading，但似乎都不起作用:

# multiprocessing attempt
@app.route('/endpoint')
def endpoint():
  def worker():
    subprocess.Popen('nohup php script.php &', shell=True, preexec_fn=os.setpgrp)

  p = multiprocessing.Process(target=worker)
  print '111111'
  p.start()
  print '222222'
  return json.dumps({
    'success': True
  })

# threading attempt
@app.route('/endpoint')
def endpoint():
  def thread_func():
    subprocess.Popen('nohup php script.php &', shell=True, preexec_fn=os.setpgrp)

  t = threading.Thread(target=thread_func)
  print '111111'
  t.start()
  print '222222'
  return json.dumps({
    'success': True
  })

在这两种情况下，我都看到了 111111 和 222222，但我的浏览器仍然挂起来自端点的响应。我已经为该进程尝试了 p.daemon = True 以及 p.terminate() 但没有成功。我曾希望在不同的 shell 和单独的进程/线程中启动一个带有 nohup 的脚本就可以正常工作，但不知何故 Flask 或 uWSGI 会受到它的影响。

更新

因为当我直接使用 python app.py 启动我的 Flask 应用程序并直接点击它而不通过我的 Nginx 代理和 uWSGI 时，这确实在我的 Mac 上本地工作，我开始相信它可能不是代码本身有问题。而且因为我的 Nginx 只是将请求转发给 uWSGI，所以我相信可能是那里的某些东西导致了它。

这是我在 uWSGI 域的 ini 配置，我在 emperor 模式下运行:

[uwsgi]
protocol = uwsgi
max-requests = 5000
chmod-socket = 660
master = True
vacuum = True
enable-threads = True
auto-procname = True
procname-prefix = michael-
chdir = /srv/www/mysite.com
module = app
callable = app
socket = /tmp/mysite.com.sock

Answer 1

这类东西是 Python Celery 的实际且可能是主要用例(https://docs.celeryproject.org/)。作为一般规则，不要在 wsgi 中运行受 CPU 限制的长时间运行的作业。过程。这很棘手，效率低下，最重要的是，它比在 celery worker 中设置 async 任务更复杂。如果你只想制作原型(prototype)，你可以将代理设置为 memory并且不使用外部服务器，或者运行单线程 redis在同一台机器上。

这样你就可以启动任务了，调用task.result()这是阻塞的，但它以IO-bound 的方式阻塞，或者更好的是你可以通过检索 task_id 立即返回并构建第二个端点 /result?task_id=<task_id>检查结果是否可用:

result = AsyncResult(task_id, app=app)
if result.state == "SUCCESS":
   return result.get()
else:
   return result.state  # or do something else depending on the state

这样你就有了一个非阻塞的wsgi执行最适合的应用程序:短时间 CPU 无限制调用，最多具有操作系统级调度的 IO 调用，然后您可以直接依赖 wsgi服务器 workers|processes|threads或者您需要在任何 wsgi 服务器(如 uwsgi、gunicorn 等)中扩展 API 以应对 99% 的工作负载，因为 celery 通过增加工作进程的数量来水平扩展。