Как я должен сохранить состояние для продолжительного процесса, вызванного от Django?

Question

Как я должен сохранить состояние для продолжительного процесса, вызванного от Django?

Я думал, что вы можете сделать скрипт, используя этот код

import sys
import ast

class visitor(ast.NodeVisitor):

    def visit_Try(self, node):
        ...

    if sys.version.startswith("2"):
        visit_TryFinally = visit_TryFinally
    elif sys.version.startswith("3"):
        visit_TryFinally = visit_Try

sys.version.startswith() для проверки версии Python.

5

python django asynchronous amazon-s3 pyro

задан Community 23 May 2017 в 12:09

3 ответа

Итак, вам нужна очередь заданий. В вашем случае я бы абсолютно согласился с БД для сохранения состояния, даже если эти состояния недолговечны. Похоже, это удовлетворит все ваши требования, и реализовать его не так уж сложно, поскольку у вас уже есть все движущиеся части, доступные вам. Не усложняйте, если вам не требуется что-то более сложное.

Если вам нужно что-то более мощное или более сложное, я бы посмотрел на что-то вроде Gearman .

1

ответ дан 13 December 2019 в 05:41

Я знаю, что это старый вопрос, но кто-то может Нахожу мой ответ полезным даже по прошествии всего этого времени, поэтому приступим.

Вы, конечно, можете использовать базу данных в качестве очереди, но есть решения, разработанные именно для этой цели.

AMQP создан именно для этого. Вместе с Celery или Carrot и сервером-брокером, например RabbitMQ или ZeroMQ .

That ' это то, что мы используем в нашем последнем проекте, и он отлично работает.

Для вашей проблемы лучше всего подходят Celery и RabbitMQ. RabbitMQ обеспечивает постоянство ваших сообщений, а Celery предоставляет простые представления для опроса, чтобы проверить состояние процессов, запущенных параллельно.

Вас также может заинтересовать octopy .

5

ответ дан 13 December 2019 в 05:41

Другие вопросы по тегам:

python django asynchronous amazon-s3 pyro

Похожие вопросы:

score 6 · Accepted Answer

Мы делаем это с помощью таблицы «Запрос» в базе данных.

Когда приходит загрузка, мы создаем загруженный объект File и создаем Request.

Мы запускаем фоновый пакетный процессор.

Мы возвращаем страницу 200 «мы работаем над этим» - она показывает запросы и их статус.

Наш пакетный процессор использует Django ORM. По завершении он обновляет объект Request. Мы можем (но не можем) отправить уведомление по электронной почте. В большинстве случаев мы просто обновляем статус, чтобы пользователь мог снова войти в систему и увидеть, что обработка завершена.

Примечания к архитектуре пакетного сервера.

Это сервер WSGI, который ожидает на порту запроса пакетной обработки. Запрос представляет собой REST POST с идентификационным номером; пакетный процессор находит это в базе данных и обрабатывает.

Сервер запускается автоматически нашим интерфейсом REST. Если он не запущен, мы его создаем. Это делает транзакцию пользователя медленной, но, да ладно. Он не должен вылетать.

Кроме того, у нас есть простой crontab для проверки его работы. Максимум 30 минут между "вы живы?" чеки. У нас нет формального сценария запуска (мы работаем под Apache с mod_wsgi), но мы можем создать сценарий «перезапуска», который касается файла WSGI, а затем выполняет POST-запрос на URL-адрес, который выполняет проверку работоспособности (и запускает пакетный процессор).