Конкурентность и масштабирование

Опция Concurrency в asynq.Config отвечает на вопрос, сколько задач один процесс берёт на исполнение одновременно. Это не число горутин в программе и не размер буфера, а ёмкость пула хендлеров. Внутри сервер работает просто: процессор в цикле берёт задачу из Redis, запускает для неё горутину с вашим хендлером, а прежде каждого забора кладёт токен в канальный семафор ёмкостью ровно в Concurrency; горутина держит токен до самого конца исполнения и возвращает его, когда хендлер закончил работу. Новый слот не откроется, пока не освободится один из занятых, — так максимальное число одновременных обработок держится точно на заданном значении. Дефолт продуман: если поле оставить нулём или отрицательным, NewServer подставит число ядер CPU, доступных текущему процессу. Очереди при этом опрашиваются не блокирующей операцией, а обычным забором: когда все очереди пусты, процессор засыпает на пол-интервала проверки плюс случайный джиттер, чтобы не долбить Redis холостыми запросами; интервал настраивается полем TaskCheckInterval и по умолчанию равен секунде. Из этого следует практичный вывод: Concurrency — потолок, а не обещание. Процесс с Concurrency 30 при пустых очередях не держит тридцать горутин — они рождаются под задачи; зато при их изобилии активных хендлеров будет ровно тридцать, а остальные задачи честно подождут в Redis.

Подбор начинается с вопроса: что делает хендлер между стартом и возвратом — считает или ждёт. CPU-bound задачи пережимают картинки, строят отчёты, шифруют: горутина почти всё время жжёт ядро, и Concurrency заметно выше числа ядер даёт только переключения контекста без прироста — держитесь ядер или чуть выше. IO-bound задачи ходят в HTTP, базы, почтовые сервисы: горутина большую часть жизни ждёт ответ, и процессор простаивает; здесь потолок ставит форму «пропускная способность, умноженная на среднее время задачи»: при десяти задачах в секунду и двух секундах на задачу нужно около двадцати слотов. Для IO-bound Concurrency в разы выше числа ядер — норма, и дефолт по CPU зря простаивает. Вторая ловушка — настоящий лимит почти всегда снаружи: пул соединений Postgres, лимит внешнего API, память машины. Concurrency 100 при пуле БД 20 означает очередь из восьмидесяти горутин внутри вашего процесса — она живёт в памяти, невидима для asynqmon и внезапно превращается в таймауты. И последнее: Concurrency читается при старте сервера — изменить его можно только новым деплоем воркеров, а гасить старые процессы надо по-честному, через дожим задач из девятнадцатого урока. Подбирают число измерением: нагрузочный стенд, Latency и Processed — ваши показания, интуиция молчит.

Когда один процесс уже набит, следующий слот добавляется новым процессом — и здесь устройство asynq играет на вас. Запустите тот же бинарник второй раз: оба процесса слушают одни очереди, и задачу при заборе уносит ровно один из них. Атомарность гарантирует Redis: Dequeue выполняется Lua-скриптом, который атомарно переносит сообщение из pending в active конкретной очереди, поэтому даже сотня одновременных заборов не выдаст задачу дважды. Пулы при этом независимы: у каждого процесса свой семафор, и два воркера с Concurrency 25 дают пятьдесят слотов суммарно. Redis остаётся координатором, но не узким местом: атомарный забор — одна короткая операция на задачу, и брокер выдерживает тысячи таких в секунду; что происходит внутри самого Redis — тема отдельного курса по go-redis. На нескольких машинах схема не меняется: воркер — дешёвый stateless-процесс с доступом к Redis, раскладывайте его по инстансам как обычный сервис. Побочный бонус — устойчивость деплоев: пока новая реплика стартует, старые продолжают забор и очередь не замирает; один процесс на время дожима замораживает мощность, а их несколько — нет. Каждая реплика сердцебиением пишет в Redis информацию о себе: хост, PID, Concurrency и карту очередей — эти данные отдаёт Inspector методом Servers(), а вкладка серверов asynqmon рисует из того же источника, так что «кто вообще обрабатывает очередь и с какой мощностью» — вопрос одного взгляда. Смерть процесса задачу не теряет: lease истекает, и работа вернётся в очередь — но повторное исполнение никто не отменял, и идемпотентность из восемнадцатого урока остаётся обязательной при любом масштабе.

Очереди из седьмого урока делят общий пул слотов пропорционально весам — и это их честная граница: рендер на десять минут и письмо на миллисекунду всё равно конкурируют за одни и те же слоты одного процесса. Взвешенный режим делает делёж справедливым, StrictPriority — строгим, но оба управляют порядком опроса, а не мощностями: отдельные мощности начинаются там, где появляются разные инстансы Server. Поднимите второй процесс с собственным конфигом: почтовый воркер держит очереди critical и default с Concurrency 30, рендерный — очередь renders с Concurrency 4. Теперь тяжёлая задача физически не может занять слоты быстрых: у рендеров свой семафор, своя машина с запасом памяти, свой темп рестартов. Клиенту ничего не меняется: постановка по-прежнему опция Queue, а исполняет задачу тот воркер, у которого очередь в конфиге; правило молчаливого ожидания из седьмого урока становится ещё важнее — очередь renders обязана жить в конфиге живого процесса. ServeMux у каждого инстанса свой: почтовый процесс регистрирует только типы писем, рендерный — только рендеры, и чужой хендлер физически не вызовется не там. Цена решения операционная: два деплоя, два набора конфигов и метрик. Взамен вы получаете класс обслуживания, который не проседает от чужой нагрузки ни при каком потоке задач.

Тикет «задачи выполняются с задержкой» диагностируется по трём числам, и все три видны в asynqmon. Первое — пара pending и active: рост pending при плоском active означает, что задачи копятся, но не забираются — процессов мало или их пулы заняты. Когда active держится на уровне суммарного Concurrency всех живых воркеров, потолок достигнут: слоты не простаивают, и обрабатываемая мощность ограничена ровно тем, что настроено. Второе — Latency, возраст самой старой задачи в ожидании: большой pending бывает и у здоровой системы, а вот растущий Latency — прямой сигнал, что конкретная задача ждёт слишком долго; порог задаёт бизнес. Третье — список живых процессов: вкладка серверов asynqmon или Servers() из Inspector показывает каждую реплику с её Concurrency и очередями; исчезнувший из списка процесс — первая причина внезапных лагов после ночи. Сравните профиль pending с вчерашним пиком: если график повторяет прошлые дни, а Latency всё равно растёт, дело не во всплеске постановок — мощности объективно перестало хватать. Если pending плоский, а задержки есть, смотрите scheduled и retry: задачи, возможно, вообще не доходят до очереди ожидания. Диагноз диктует лекарство: пул занят — добавляйте процесс или поднимайте Concurrency; тяжёлое душит быстрое — разделяйте инстансы; процессы живы, а очередь стоит — проверяйте, ту ли очередь слушает воркер. Наблюдаемость в метриках и алертах — отдельная тема двадцать третьего урока.