4kpt_IV
Ну а как вы предлагаете мне принимать данные от сайта на стороне сервера? У меня уже была самописная очередь… Даже страшно вспоминать… Потом я попробовал RabbitMQ напрямую, писал сам код. Кода стало гораздо меньше. А уже потом стал использовать Redis с RedisQ. Код сократился до пары строк. Celery меня не устроил своей пухлостью, сам по себе.

Пока другого способа доставки задачи я не знаю. Ведь надо понимать, что к одной очереди подключено несколько серверов. Я кидаю задачу и кто ее возьмет меня не интересует. Есть вариант с API. Но я еще не достиг того уровня чтоб для себя внятно сформировать что это и как это кушать. Но, опять же, где в этом варианте очередь? Нету. API в моем понимании – сбор статистики. И то как посмотреть.

Вы понимаете, что RQ и сельдерей это не очередь? Он не служит для передачи данных. Проще написать свой механизм передачи через очередь и не мучатся. Получается, что Вы эту махину раскручиваете только ради того, чтобы данные из одного сервера передать на другой.

Сервера физически разнесены или это просто разные приложения?

4kpt_IV
Да, сервера разнесены.

Подождите. Celery и RedisQ сами по себе не Queue. Это да. Но для этих целей они используют RabbitMQ и Redis. Разве не так? Но в Celery тож придется, как и в RedisQ, указывать что я хочу выполнить на удаленном сервере. И либу нужно будет иметь на двух серверах. В случае с RedisQ (на Celery возможности проверить не было, но думаю там тож должно работать) название либы передается в виде строки, а уже на стороне сервера (воркера) выполняется callback. В таком варианте очень удобное использование. Нет?

На счет передачи данных я не очень понял. Как тогда вообще использовать очередь? Кидаем задание и оно будет выполнено каким-то ворвером. Но данные что делать и с какими данными что делать надо же как-то передать. Тут я вас не понял.

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

Какие данные? Если сервера разнесены физически - передайте json объект и все.

Я несколько раз спросил где модели и БД находятся. Не зря к слову. Вы не даете понять полную картину и задает вопросы на которые я не смогу ответить.

Думаю что к концу разработки django и база будут на разных серверах.

4kpt_IV
Для задач без временных вызовов RQ самое оно.

Если вы про scheduler, то в RedisQ оно есть, просто отдельно ставится.

4kpt_IV
Если сервера разнесены физически - передайте json объект и все.

Куда передать? Задача отказаться от знания что где-то есть сервер. И очередь это позволяет. Серверов может быть 10 или 20. Я просто говорю что нужно, а в отдельной очереди могу получать результат (ну или обращаться к Redis запрашивая результат работы).

k0st1an
то в RedisQ оно есть, просто отдельно ставится.

В RQ нет полноценного sheduller. То, что ставится - очко полное. Уже со славоником немного пообщались на эту тему.

k0st1an
Куда передать? Задача отказаться от знания что где-то есть сервер

Вы это знание заменяете знанием, что где-то есть очередь. В чем разница, поясните… Хотите очереди - не вопрос. Пусть будут очереди. Возьмите тот же redis и напилите к нему обертку, которая реализовывает обмен данными. Возможно уже есть готовые решения даже, можно поискать. Или возьмите специализированную очередь для таких задач. Но все равно алгоритм получения задачи из очереди и запихивание (не запихивание) результатов в очередь нужно будет реализовать самому. Но это будет правильное решение. А не использовать механизм отдельного выполнения тяжеловесных задач для передачи данных между серверами / сервисами.

P.S. А модель где? Третий раз спрашиваю. Возникаю ощущения, что Вы не знаете как оно у Вас там, а только вкатываетесь в проект

4kpt_IV
В RQ нет полноценного sheduller. То, что ставится - очко полное. Уже со славоником немного пообщались на эту тему.

Видел в описании, сам не юзал.

Я понял про что вы. И кажется да, это не совсем верное использование RedisQ. Но с другой стороны если я что-то свое буду пилить, огребу кучу ошибок (с ужасом вспоминаю первый обмен между серверами).

С другой стороны те презентации и видео с конференций, что я видел, везде есть что нужно выполнить и с какими параметрами. Обычно это 2+2. Но суть дела не меняет, это может быть и {'a': 12, ‘b’: ‘define’}. Ну фактически одно и тоже. В чем тут разница, я не очень понимаю. И обычно, да, докладчики говорят про отправку почты, еще какую-то рассылку. И как бы все это работает на одном сервере.

Еще важно то, что в один момент времени сервера могут быть заняты. И тогда сам принцип очереди очень даже удобен. С другой стороны, посылать содержимое PDF файла через очередь – бред. Я же использую тот же JSON, только в варианте dictionary. Ну можно в JSON преобразовать. Просто лишнее действие.

4kpt_IV
А модель где?

Вам саму модель показать? Что это изменит? Она там большая..

k0st1an
Вам саму модель показать? Что это изменит? Она там большая..

У меня возникает ощущение, что Вы меня троллите
На каком из серверов модель???

django + model (db?!) – srv1
redis – srv2
some app – srv3, srv4, srv5, …

Видимо model в Вашем понимание db. Я просто Вас не понял

Модель это в моем понимании модель. База - это база.

Поясню почему я расспрашиваю.
Представим, что у Вас есть тяжелая задача. Мало того, ее тяжесть связана еще и с тем, что там много данных нужно получать из БД. Как в этом случае будете делать? Что Вы передадите на RQ? Данные предварительно получите из БД?

Теперь конкретнее. Удаленный менеджер задач делается как полноценное приложение. Со своими доступами к БД, со своим механизмом получения данных (очередь там это или просто json не имеет никакого значения). Тем более, что Вы уже направились все это дело разносить. Если на одном сервере, тогда используется общая модель (почему я никогда не использую Flask-Alchemy а чистую алхимию). Если на разных серверах можно использовать разные модели и общую БД. Опять же, это если нужны дополнительные запросы к БД для выполнения поставленной задачи. Но все равно, даже если данные получать и не надо, то для обмена данными между “задающим задачу” и “выполняющим задачу” должна быть очередь. А не RQ и уж тем более не Celery. Мало того, если я не ошибаюсь, то RQ при каждом запросе будет инстансировать Вашу задачу.