в первый

я правильно понял твою логику?

Нет воркер должен быть один, но с несколькими под-процессами (например по числу ядер).
Консьюмер слушает две очереди (high и low), он может "одновременно" получать из них сообщения, но отправлять их в "процессы" для выполнения должен только в соответствии с приоритетом этих сообщений. Приоритет определяется на основе приоритета очереди + время, которое прошло с момента последнего запуска тасок из других очередей. Т.е. там должна быть какая-то балансировка например на основе рандома с весами. Из двух имеющихся "на руках" задач выбираем для запуска рандомно одну с учётом "веса" этих задач.

Отдельный "воркер-балансировщик" не получится сделать нормально. У него нет информации о времени, которое тратися на выполнение каждой таски в отдельном "воркере-исполнителе"

ну так у тебя его и не будет, если задачи работают с сетью

да и не все обычные задачи сможеш делать за одно и тоже время

если только статистику собирать и расчет делать на среднем

Стабильное и фиксированное время работы одной таски не важно. В этом и суть. Если таски из high очереди очень долго работали и не давали запустится таски из low очереди, то это должно повысить приоритет следующей таски из low очереди.

понял

надо обдумать

но даже в такой постановке мне кажется это получится реализовать поверх того же celery или dramatiq

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

Не уверен что там есть какие-то "хуки", что бы вмешаться в его работу.

относительно недавно смотрел код селери 4.х
Там тупо сделано, аля

for queue in queues:
     task = queue.get(no_wait) 
     if task:
             schedule(task)

но я не думаю что твоя идея реализуема на абстрактных очередях. Так как тебе надо попытаться взять сообщение из Low priority queue. Проверить время создании задачи и запихнуть её обратно, если время не пришло..

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

Забавный факт. pyodbc.connect игнорирует timeout для подключения к серверу если вы используете драйвер FreeTDS, а в connection string пишете SERVER=. Стоит заменить SERVER= на SERVERNAME=, и, о чудо, коннект отваливается по таймауту.

ммм, что не уж то от спамеров нету защиты?

и кстати, зачем они снаала одну фотку засылают, а потом меняют на другую?

Попытка ввести человека в заблуждение, чтобы модератор не подумал, что это бот. Только задержку надоставить побольше, вероятно мамкины хакеры по методичке пишут, потому вроде работает, но как-то бессмыслено. И беспощадно)

Против лома нет приёма. Попытка защититься от отключения интернета приводит к отключению интернета) Придётся терпеть ботов.