LINUX.ORG.RU

С помощью каких инструментов такое делается?

 , ,


0

2

Всем привет. Вопрос насчет celery или агрегации сообщений. Обычно веб работает так:

user1          user2    
  |              |
message       message
  |              |
celery        celery
  |              |
task1          task2   и т.д.

Как добиться такого(ниже)? Какой инструмент для этого есть?

   user1   user2      user3 (и т.д.)
    |       |           |
   message  message   message
    |_______|___________|
        |
     aggregator message (data list [] )
        |
      celery
        |
      будет решать одну задачу (потоки, или асинхронное выполнение)

В celery конечно есть всякие методы (group,chunk) для обработки тасков, но вроде чтоб добиться такого нет.


Обычно веб работает так

Нет, он работает вот так:

user1-taskA   user2-taskB      user3-taskA (и т.д.)
    |_____________|_________________|
        |
      celery
        |
    |-----------------|
 (taskA-workers)  (taskB-workers)
    |                      |
|------------|          |------------|------------|
workerA-1  workerA-2    workerB-1   workerB-2  workerB-3

Соответственно "будет решать одну задачу (потоки, или асинхронное выполнение)" - это просто один воркер на очередь заданий определенного типа.

micronekodesu ★★ ()
Ответ на: комментарий от micronekodesu

Кстати столкнулся с тем, что те кто используют сельдерей по большему счету его и использовать то не должны. Кто мешает сразу кролику слать данные сериализованные. Сельдерей иногда дико вредит.

dem ★★ ()
Ответ на: комментарий от Cirno

Например очень часто передают в селери объект. А потом удаляют его, а воркер не в курсе. А надо передавать ID и в воркере читать ID и фетчить его. Тоесть это типичные https://a32.me/ru/2013/03/ne-dajte-astronavtam-arhitektury-vas/ Это самая простая проблема. Но еще за счет конфига кролика можно и накрутить всякие биржи и роутинг

dem ★★ ()
Ответ на: комментарий от micronekodesu

потоки или асинхронщина, я имел ввиду выполняться будет самим таском. Т.е. чтоб в задачу передать лист данных [] и его распараллелить. Как раз для того чтобы очередь не делать из тасков. Я просто х.з. как обяснить еще.

bikes ()
Ответ на: комментарий от bikes

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

В общем, могу предложить два варианта, оба кривые-косые - вычитывать очередь через https://docs.celeryproject.org/en/latest/userguide/workers.html#inspecting-wo... или писать какую-то прослойку, которая будет просто выгребать данные из очереди и хранить их "у себя", а потом после выполнения какого-то условия передаст их тому воркеру, который должен эти задачи обрабатывать.

В обоих случаях вы просто добавляете проблем на ровном месте и я надеюсь что все это кроме вас никто не увидит и поддерживать не будет. Если вам нужно нормальное решение - напишите что именно вы хотите сделать, и вам помогут сделать это правильно.

micronekodesu ★★ ()
Ответ на: комментарий от dem

Кто мешает сразу кролику слать данные

Это как с джангой. Типа "зачем мне что-то писать самому, я лучше возьму готовый комбайн". В итоге половина функций просто не используется, половина - вредит, статичный лендинг "я и моя кошка" содержит 420 моделей и 69 модулей.

micronekodesu ★★ ()
Ответ на: комментарий от micronekodesu

Вы в правильном направлении подумали. Т.е. нужно за какое то время собрать данные, вытащить их (смержить в лист) и отправить на выполнение, для решения одним таском (а там уже в многопотоке их обработать). И еще надо как то обратно ответ отдавать. Почему для этого решений нет из коробки. надо какие то костыли городить… или я хочу странного? Пример: задача занимает пару минут. Нам надо обработать 10 входных данных. В многопотоке это будет примерно тоже время около 2 мин. А если запускать как обычно сельдерем из коробки, то это будет 10 * 2. Или надо увеличивать concurrency, чтоб они одновременно обрабатывались и соответственно время двигалось в меньшую сторону.

bikes ()
Ответ на: комментарий от bikes

или я хочу странного?

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

нужно за какое то время собрать данные, вытащить их (смержить в лист) и отправить на выполнение

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

micronekodesu ★★ ()
Ответ на: комментарий от micronekodesu

В целом это будет примерно то же самое, что вы нарулите через мультитрединг

Благодарю за объяснение. До меня только сейчас дошло, моя задача связана с внешними сетевыми запросами. Может надо в таком случае отказаться от prefork и использовать gevent или eventlet?

bikes ()
Последнее исправление: bikes (всего исправлений: 1)
Ответ на: комментарий от bikes

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

micronekodesu ★★ ()
Ответ на: комментарий от Cirno

Ну например в Джанге передают не id юзера, а его объект. По каким то причинам celery немного подтормозим и в тот момент когда этот запрос попал к воркеру в базе такого объекта нет. Долго будешь отлавливать. Кроме того тот же рэббит очень неплохо настраивается и переконфигурируется. Ничего сложного передать в него сериалиизованные данные которые нужны воркеру. Отладка тоже - запустил реббит и шли json. В общем за 2 года работы с Celery я вернулся на rabbit и не вижу от ЕЩЕ одной прослойки плюсов. (Поправьте)

dem ★★ ()
Ответ на: комментарий от Cirno

Это обманка. Выглядит как голая баба, но это надувная баба… как то так. Настоящая может быть не такая и красивая. Нагуглите про проблемы с селери. Там иногда люди вообще не понимают что происходит.

dem ★★ ()
Ответ на: комментарий от dem

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

Я запросил подписку, только с другого аккаунта.

WitcherGeralt ★★ ()