Возьмите себе rabbitmq и не страдайте

И да, expire еще проверяется в самом селери дополнительно

хз, я redis юзал бы в качестве очерели только если могу в любой момент взять и перегенерировать всю очередь

Так же, как и eta

Возьмите себе rabbitmq и не страдайте

А он научился в ipv6 таки?

Без понятия, к сожалению, но мне кажется, это прямо не такой существенный минус, что бы его не брать.

Возьмите себе rabbitmq и не страдайте

А он гарантирует expire по времени точно?

хз, я redis юзал бы в качестве очерели только если могу в любой момент взять и перегенерировать всю очередь

Еще одна плюшка - селери дает один интерфейс к разным брокерам

Вам вот прямо нужно точно или +- 1-5 секунд?)

Пара секунд не проблема.

Но не минус

Еще одна плюшка - селери дает один интерфейс к разным брокерам

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

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

Пара секунд не проблема.

Ну, минут это я загнул. https://www.rabbitmq.com/ttl.html а так вообще написано, что he server guarantees that dead messages will not be delivered using basic.deliver (to a consumer) or included into a basic.get-ok response

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

В основном работает только в условных базовых кейсах

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

TTL - мы точно про очередь задач?

У задач же бывает ttl, разве нет?

лично я 1. не вижу в нем смысла 2. не представляю как его нормально юзать когда у тебя проект состоит из частей на разных языках 3. плохо представляю как рефакторить код работы с тасками

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

TTL - мы точно про очередь задач?

Про отложенные, которые должны выполнится спустя N

У задач же бывает ttl, разве нет?

наверно, но имхо это нетипичное применение

Про отложенные, которые должны выполнится спустя N

TTL это не про отлоденные задачи. Это про удаление

Про отложенные, которые должны выполнится спустя N

Это все-таки ETA в рамках celery

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

да есть реализации слеери под разные языки

TTL это не про отлоденные задачи. Это про удаление

Это всего лишь частный случай таймера, например, в редиске.

интересно как Celery сделает ETA в случае rabbitmq не заблокировав всю очередь?

да есть реализации слеери под разные языки

ну как бы формат сообщения там не сложный, JSON получить ты можешь из другого языка.

Просто в нормальном брокере сообщений есть прямо "отложенные сообщения"

интересно как Celery сделает ETA в случае rabbitmq не заблокировав всю очередь?

У rabbitmq есть встроенный eta

Помоему из всех mq только у него как раз и есть

В редиске есть ета. НО ЕСЛИ ВНИМАТЕЛЬНО ПОЧИТАТЬ, то сорямба

в SQS например нету отложенных сообщений если очередь с гарантией порядка

Чуваки, задумайтесь, как вы будете реализовывать отложенный таск на пайтоне голом или другом ЯП?

вообще не представляю как

В python на асинхронщине можно проще простого :)

положу в БД и буду поллить =D

А так зависит от требований

Чуваки, задумайтесь, как вы будете реализовывать отложенный таск на пайтоне голом или другом ЯП?

при помощи отдельного schedulera видимо

положу в БД и буду поллить =D

+

но с поллингом БД есть проблемы с exactly one выполнением

Я бы все-таки взял rabbitmq или богопротивных nats

У меня так сервис уведомлений так и работает, сами задачи в БД, а распределение задач работает на nats

но с поллингом БД есть проблемы с exactly one выполнением

можно лочить на каждый полл, но это звучит как боль

но с поллингом БД есть проблемы с exactly one выполнением

эм… rabbitmq если что тоже не дает гарантии exactly one

эм… rabbitmq если что тоже не дает гарантии exactly one

Разве?

Разве?

да

А, да

кафка даёт xD

ну у меня и не было rabiitmq ни разу

кафка и sqs только

В python на асинхронщине можно проще простого :)

Я пробовал. Получается тоже самое, что в редиске. ВОт сука один в один

Никаких гарантий?

Угу.

Ну, в теории оно так и есть, у вас есть только гарантия, что "выполнится не раньше"

Но в целом если пул очередей сильно забит, то может и очень поздно выполнится

Блядь, ебаный TImer в трединге нихуя не гарантирует.

Ну, он гарантирует, что выполнится "не раньше", по идее

Разве нет?

У меня выполняется раньше с каких-то херов. Бо есть замечательный нотифай_алл

КОторый где-то под коробкой раз в триста лет отрабатывает

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

Так-с, на заметку, если кто-то будет долбатся с asyncio + opentracing, их AsyncioScopeManager полный шлак, так как построен не на contextvars

А на атрибутах объекта Task (

Я новичок в бэкенде. Знаю js и python. Сейчас решаю задачки на leetcode. Вопрос таков. Какой фреймворк изучить для бэкенд? Я знаю mongoDB и буду писать в основном Rest API. Ответы пожалуйста с аргументами. Спасибо

Flask или Django?

ну писец. Это как спросить - сосиски или сардельки...

Попробуй и то, и другое.

ну писец. Это как спросить - сосиски или сардельки...

сардельки

сосиски

нет сардельки

с аргументами есть около сотни статей сравнения

нет сардельки

а мне сосиски

котлетки!

типа топ5 веб фреймворков

Какая нахер разница

любой фласк в итоге превращается в джанго))

В разных местах разное используется. Джанго позволит быстро сделать сервис, фласк даст больше гибкости. Полезно знать оба.

любой фласк в итоге превращается в джанго))

точно не наоборот?

Окей. Уточню. С какого начать сперва

с aiohttp

С какого хочешь

Flask или Django?

https://tproger.ru/translations/django-faq/ Первый пункт в этой статье - аргумент

https://tproger.ru/translations/django-faq/ Первый пункт в этой статье - аргумент

Какая-то спорная и однобокая статья

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

"Создать свою собственную платформу то же самое, что написать новую ОС. Зачем возиться?" это он так настройку nginx приравнял к написанию собственной ОС

Какая-то спорная и однобокая статья

Ну потому что это FAQ по Джанго, что ж она должна быть двубокая)

Ну потому что это FAQ по Джанго, что ж она должна быть двубокая)

Это не фаг по Джанго, это набор спорных утверждений, не специфичных для джанго

Как в аннотации указать тип event loop'a, aiohttp web session?

Зависит от проекта: я говорю я новичок в бэкенд

Ну потому что это FAQ по Джанго, что ж она должна быть двубокая)

я вижу только спорные категоричные утверждения без внятной аргументации

Зависит от проекта: я говорю я новичок в бэкенд

Бери Джангу. В неё проще вникнуть, потому что она уже предоставляет решения для проблем, которые без Джанги тебе придется решать самому

В джангу проще вникнуть?

Я как ни попытаюсь к ней подойти - возникают мысли "а почему это так?"

Лучше bottlepy, в нём вообще ничего лишнего нету

Только не джанга