Архитектура бэкенда
Async vs blocking: тест с множественным выбором
Суть Синтез с множественным выбором по всему юниту async/blocking — модели I/O, расписание event loop, что его блокирует, вынос CPU-работы, ограниченная конкурентность и хвостовая задержка под нагрузкой.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов через весь юнит. Каждый отражает решение, которое ты принимаешь в реальном инциденте — не определение для зубрёжки, а компромисс, который надо взвесить, пока loop горит, а хвост растёт.
Цель
Убедись, что ты связываешь модель I/O, расписание event loop, что его замораживает, куда выносить CPU-работу, как ограничить fan-out и почему хвост взрывается у насыщения — синтез, к которому вели шесть уроков.
Викторина
Completed
Сервис A — thread-per-connection приложение, держащее 50 000 в основном простаивающих keep-alive сокетов; сервис B делает то же на event loop. Оба почти простаивают по CPU. Почему A падает, а B чувствует себя комфортно?
Heads-up Простаивающие блокирующие потоки паркуются ОС, а не крутятся — CPU у A остаётся низким. Цена — это память под стеки и накладные расходы планирования, а не спин CPU.
Heads-up Лимиты FD — настраиваемый per-process параметр, не зависящий от модели I/O; оба упираются в один лимит ядра. Реальная разница — в стоимости потока на соединение.
Heads-up Задержка одного чтения по сути та же; epoll/kqueue меняет лишь то, как ты узнаёшь, какие сокеты готовы, а не скорость отдельного чтения.
Викторина
Completed
Внутри I/O-колбэка ты планируешь setTimeout(a, 0), setImmediate(b) и Promise.resolve().then(c). Что выполнится первым и какой принцип это решает?
Heads-up Порядок исходника никогда не решает выполнение в event loop; решают фаза колбэка и дренаж microtasks. Promise-реакция обгоняет оба macrotask.
Heads-up Наоборот: microtasks имеют более высокий приоритет и дренируются до пустоты после каждого колбэка, так что promise-реакция выполняется раньше любого таймера или setImmediate.
Heads-up Loop — один поток; эти колбэки в очереди и упорядочены, никогда не одновременны. Потоки libuv выполняют нативный I/O, а не твои JS-колбэки.
Викторина
Completed
Двухстрочный эндпоинт /health начинает таймаутить, но только когда дёргают route отчётов. Этот route запускает JSON.parse на теле 40 МБ. Почему страдает health и какой сигнал диагностики правильный?
Heads-up Health не трогает БД, а JSON.parse не открывает соединений — это чистая CPU-работа в памяти. Монополизируется поток loop, а не соединение.
Heads-up Здесь нет per-route планирования ОС — это один поток. И высокий CPU может быть здоровым; вернее сигнал event-loop lag — разрыв между тем, когда колбэк должен был выполниться, и когда loop до него добрался.
Heads-up Пул libuv выполняет нативный I/O, а не твои JS-обработчики, а парсинг — это JS на loop. Расширение пула ничего не даёт для заблокированного loop.
Викторина
Completed
CPU-тяжёлый ресайз картинки (чистый JS) замораживает loop. Один инженер поднимает UV_THREADPOOL_SIZE с 4 до 32; другой переносит ресайз в worker thread. Кто починил и почему?
Heads-up Пул libuv никогда не выполняет JavaScript, поэтому не может запустить ресайз при любом размере. Его расширение помогает, лишь когда упираешься в пропускную способность нативных fs/dns/crypto.
Heads-up Они не эквивалентны — только worker thread выносит JS с loop. Изменение пула — no-op для этого бага и классическая ловушка на потерянную неделю.
Heads-up Ресайз — это CPU-bound вычисление, именно поэтому он замораживает loop и должен быть вынесен в worker (или разбит на чанки).
Викторина
Completed
Миграция запускает await Promise.all(millionIds.map(processUser)) и её OOM-килит до того, как завершится первая тысяча, пока БД отказывает в новых соединениях. Корневая причина и фикс?
Heads-up Promise.all ведёт себя точно по спецификации — стартует каждый промис немедленно. Вред — в неограниченном числе одновременных операций, а не в дефекте.
Heads-up Колбэки map не блокируют loop; они I/O-bound и уступают управление. Проблема в том, сколько их выполняется одновременно, а не в том, что какой-то один блокирует.
Heads-up Больше кучи лишь отсрочит OOM и всё равно затопит БД сверх её лимита соединений. Надёжный фикс — ограничить конкурентность до того, что downstream способен принять.
Викторина
Completed
Node-сервис сидит на 75% CPU со средним 20 мс; небольшой всплеск трафика поднимает CPU до 82%, а p99 прыгает с 80 мс до 1400 мс, пока среднее почти не двигается. Как это читать?
Heads-up Ничто не указывает на утечку; нелинейный скачок — это кривая очереди у насыщения, свойство нагрузки. Среднее, читающее 'всё ок', и есть ловушка.
Heads-up p99 здесь и есть значимый сигнал — он выявляет насыщение, которое среднее скрывает, а fan-out делает этот хвост 1-из-100 типичным опытом страницы с множеством вызовов.
Heads-up Один Node loop — это одно ядро JavaScript; лишним ядрам нужны лишние loops (cluster/инстансы). Глубже фикс — работа с запасом ниже колена, а не погоня за обрывом железом.
Итог
Сквозная линия юнита — одна цепочка решений: модель I/O задаёт, как ты тратишь ожидание (парковать поток vs мультиплексировать на loop), фазы loop и дренаж microtasks задают порядок колбэков, любой синхронный участок на loop замораживает все соединения сразу, CPU-bound JS живёт в worker thread (а не в большем пуле libuv), а длинная-но-делимая работа может разбиваться на чанки, fan-out надо ограничить до того, что downstream принимает, и у насыщения очередь взрывает хвост — поэтому смотришь p99 и event-loop utilization, а не среднее, и работаешь с запасом.