Несколько очередей и приоритеты

Asynq очереди настраиваются полем Queues в asynq.Config — это карта «имя очереди: вес». Вес — сколько голосов очередь имеет при каждом выборе следующей задачи: конфиг critical 6, default 3, low 1 означает, что при непустых очередях примерно шестьдесят процентов опросов уйдёт критической очереди, тридцать — обычной и десять — низкой. Если Queues не задан вовсе, сервер обрабатывает только очередь default — по этой причине первые дни курса всё и работало. Очередь с нулевым или отрицательным весом игнорируется: неактуальные очереди из конфига проще убрать, чем оставлять с нулём. Валидация имён при этом нарочито скромная: NewServer молча пропускает невалидные имена — пустые или состоящие из пробелов, — так что конфиг с опечаткой не уронит старт, а просто оставит очередь без обработчика, и задачи в ней будут ждать так же тихо, как при расхождении клиента и сервера. Вторая сторона — клиент: очередь назначается на постановке опцией asynq.Queue("critical"), и задача помнит своё место в поле info.Queue. Без этой опции задача едет в default независимо от того, какие очереди настроены у сервера. Заметьте асимметрию: клиент может поставить задачу в любую очередь, но исполнять её будет только воркер, у которого эта очередь прописана в конфиге — расхождение ловится не ошибкой, а тишиной ожидания. Имя очереди — непустая строка: библиотека валидирует только это, поэтому дисциплина имён целиком на команде; lowercase и дефисы — та конвенция, которая не выглядит умной до первого тикета «в какой из четырёх регистров очередь Critical».

У весов есть два режима работы, и разница между ними — главное решение урока. По умолчанию StrictPriority выключен, и порядок опроса очередей перемешивается: сервер собирает список имён, повторяя каждое столько раз, каков его вес, тасует его и опрашивает в получившемся порядке. Отсюда и проценты из документации: 6/3/1 даёт примерно 60/30/10 процентов обработки — low гарантированно выполняется в зазорах, хотя и редко. Включённый StrictPriority превращает порядок в дедикт: очереди выстроены по убыванию веса, и пока в critical есть задачи, до default и low дело не доходит вообще. Строгий режим предсказуем для критической очереди — её задержка почти не зависит от длины остальных, — но делает низкоприоритетную работу заложником потока в critical. Стоит понимать и устройство взвешенного режима до конца: сервер собирает список из шести критических, трёх обычных и одной низкой, тасует его и убирает повторы, сохраняя первый порядок появления — поэтому проценты приблизительные и от опроса к опросу прыгают, но в среднем сходятся к пропорциям весов. На короткой дистанции это значит, что из десяти опросов подряд low может достаться два, а может ни одного: вес обещает долю, а не ритм. Выбор между ними — выбор между справедливым дележом и жёсткой гарантией: первого достаточно большинству систем, второй нужны тогда, когда у critical есть настоящее SLO, а низкоприоритетные задачи умеют ждать сколько угодно.

Хендлеру всё равно, из какой очереди пришла задача: маршрутизацию по типам делает ServeMux, а очередь — это канал обслуживания, и живут они в разных измерениях. Один и тот же тип задачи может ходить в разных очередях: письма для обычных пользователей — в default, письма для VIP-клиентов — в critical, при этом хендлер один и код постановки различается одной опцией. Поле info.Queue после постановки говорит, куда задача легла, — логируйте его вместе с ID, чтобы при разборе жалобы сразу видеть класс обслуживания. Имя очереди входит и в ключ уникальности: постановка с Unique считает задачи различными, если у них разные очереди, поэтому одна и та же рассылка может одновременно существовать уникальной копией в default и в critical без взаимного конфликта. В asynqmon очереди отображаются отдельно: по каждой видно длину, скорость обработки и количество повторов — это удобная точка, где классы обслуживания становятся числами, а не ощущениями. Единственное жёсткое правило связки клиент-сервер: очередь из постановки должна быть в конфиге хотя бы одного живого воркера, иначе задача будет ждать молча. Проверка простая: конфиг воркера — это белое имя очередей, а постановщик не имеет права использовать ничего вне этого списка.

Приоритеты задач go на практике сводятся к разметке по одному вопросу: сколько мы готовы ждать выполнение этой задачи в час пик. Critical — то, за чем цена задержки денежная или репутационная: подтверждения платежей, сброс пароля, вебхуки со сроком по договору. Default — обычный фон: письма, уведомления, отчёты по кнопке; минуты ожидания пользователь не замечает. Low — работа, которую можно прервать и возобновить без всякого вреда: пересчёты рейтингов, пережим картинок, выгрузка аналитики, индексация. Правило, которое держит систему понятной: очередь — это класс обслуживания, а не тема проекта. Очередь «письма» ни о чём не говорит — письмо о сбросе пароля и дайджест новостей живут в разных классах. Если вы пришли из RabbitMQ, где приоритет сообщения — свойство брокера и его очереди, здесь механика на стороне приложения: asynq просто честно перемешивает имена очередей при опросе Redis. Имена весов не абсолютны — важны пропорции: 60/30/10 и 600/300/100 дают одно и то же поведение.

Очереди в asynq дешёвые: заводятся записью в карте, без миграций и объявления в Redis. Но у каждой есть две цены. Первая — операция опроса: воркер проверяет настроенные очереди при каждом выборе задачи, и двадцать очередей означают двадцать проверок в обход почти пустых. Когда очереди пусты совсем, воркер засыпает примерно на секунду — интервал настраивается полем TaskCheckInterval — и просыпается снова; очередь вне конфига не опрашивается никогда, чем бы она ни была полна. Вторая — конфигурационная: очередь живёт в трёх местах сразу — в постановках клиента, в конфиге каждого воркера и в дашборде — и расползание этого списка замечается по симптомам, а не по ошибкам компиляции. С масштабированием очереди связаны напрямую: все реплики воркеров могут слушать одни и те же очереди — тогда общий пул слотов делится пропорционально весам, — а можно разделить деплой: пара реплик только на critical, остальные на всё остальное. Вариант с разделёнными деплоями дороже в сопровождении, зато тяжелая low-работа физически не может занять слоты критического пула. Полный разбор обоих вариантов, включая связь с Concurrency, ждёт в двадцатом уроке. Стартовая рекомендация простая: одна очередь default, вторая — по первому реальному симптому конкуренции.