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

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

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

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

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

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

Можно подробнее? Если не сложно.

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

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

Просто думал что лишний раз фетчить не производительно, ведать не сталкивался ещё там где это слишком сильно мешало, во всяком случае спасибо.

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

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

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

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

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

Да да. Типа прозапас

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

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

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

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

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

Тебе не нужен Celery, тебе нужен RabbitMQ.

да ему и редиса хватит

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

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

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

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

Спасибо за то что объяснил позицию, просто в селери это так выглядит все однородно, или можно в духе селери писать на голом кролике?

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

Ты джаббером не пользуешься? Дело есть.

был.. demmsnt AT jabber.ru

Тю сам спросил и сам свой контакт отозвал….

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

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