Как правильно реализовать многопоточный демон с REST API?

Question

[Tony]

Мне требуется написать многопоточный (или многопроцессный?, или асинхронный?) демон, который будет предоставлять API (REST) и выполнять некие паралельные задачи в фоне. Такие приложения я никогда не писал и плохо понимаю принцип работы многопоточных и асинхронных приложений. Принцип работы мне представлялась примерно такой: главный процесс, который запускает дочерние процессы с API и фоновыми задачами, дочерние процессы пораждают еще процессы или потоки, если потребуется. Когда стал искать, как написать API (взял flask), прочитал про то, что для работы требуется WSGI сервер. Пробовал искать иформацию, как написать многопоточный демон с API, но ничего не нашел. Пришла идея сделать два приложения, но она мне не очень нравиться. Сейчас смотрю, как сделать такую схему на java.

1) Правильно ли я понимаю принцип работы многопоточного демона (или что можно почитать про многопоточность и асинхронность)?
2) Можно ли реализовать такое приложение на python?
3) Не будет ли проще написать такое приложене на java?

Comments

[tkutru]

Разбейте задачу на составляющие:
1.) Вебсервер и бизнес-логика API
2.) Фоновая обработка

Начните с п.1, т.е. реализуйте простейшее API с обычной обработкой. Потом переведите обработку на фон.
Я бы сделал через очереди, т.е. API создает какую-то задачу с параметрами и id в бд, ставит сообщение в очередь и в ответе отдает id задачи, типа "узнавайте готовность задачи по этому id".
Далее брокер отдает сообщение консьюмеру (обработчику), тот обрабатывает задачу и обновляет ее статус.
Если потребуется параллелить нагрузку, просто добавляете дополнительные обработчики.

Answer 1

[malbaron]

1. API REST, как правило, именно stateless. То есть каждый вызов API совершенно не зависит от другого.
Таким образом, вся многопоточность остается внутри, а не на вашем REST API

2. Самое большое неудобство для программирования - это блокировки/синхронизации. То есть когда вы используете общие ресурсы, которые не позволяют обращаться к ним конкурентно-параллельно, такие нужно блокировать на время использования. Но эти блокировки, в свою очередь, могут вызвать deadlock.
Блокировать нужно не забывать. Но нужно это делать минимально, только когда нужно. Например, возможно, достаточно будет не exclusive lock, а всего лишь rw-lock на read.

3. Реализовать проще на том, что лучше знаешь. Я бы выбрал Go, но это я. Реализовывать нужно на том, что лучше знаешь лично ты.

Answer 2

[Dmtm]

я бы сделал общую очередь (Deque) запросов, FIFO,
ждущий исполнитель запросов, забирает задачи из начала очереди, активируется при попадании очередного запроса в очередь,
настраиваемый пул потоков для распараллеливания
при желании можно добавить валидацию запросов и например, не прошедшие - ставить в конец очереди (почитать про poison request messages)

Answer 3

[Tony]

Нашел фреймворк bottle и примерную реализацию того, что хотел сделать. Один процесс обрабатывает апи а второй что то делает в фоне. Надеюсь никаких неприятностей не возникнет при такой работе.

from multiprocessing import Process
from bottle import Bottle, run
import time
import os

app = Bottle()


@app.route('/')
def index():
    return 'Hello !'


def child():
    while True:
        time.sleep(10)
        pid = str(os.getpid())
        print(pid + ' PID \n')


def api():
    run(app, host='localhost', port=8000)


def main():
    process1 = Process(target=child, args=())
    process2 = Process(target=api, args=())

    process1.start()
    process2.start()

if __name__ == '__main__':
    main()