Worker threads и кластеризация

Стена одного потока

Node исполняет твой JavaScript на одном потоке. Для I/O это преимущество: await fetch() или await db.query() паркует работу в libuv или в ядре ОС, и event loop идёт дальше, так что один поток жонглирует тысячами конкурентных соединений почти бесплатно. Модель ломается ровно в тот миг, когда работа становится CPU-bound — хэширование пароля через bcrypt, трансформация картинки, gzip полезной нагрузки, парсинг 20-мегабайтного JSON-тела или JSON.parse над огромной строкой. Ничто из этого не уступает loop’у. Пока оно бежит, loop заблокирован: ни колбэков, ни таймеров, ни новых запросов — для каждого клиента, а не только для того, чей запрос это запустил.

Официальный совет — Don’t Block the Event Loop — это и есть вся суть. Синхронная CPU-задача на 200 мс — это не «на 200 мс медленнее для того юзера»; она добавляет 200 мс head-of-line задержки каждому запросу, уже стоящему в очереди за ней. Выходов ровно два, и они отображаются на две разные проблемы:

• Больше потоков в одном процессе — worker_threads — для CPU-параллелизма с опциональной общей памятью.
• Больше процессов — cluster или N реплик за балансировщиком — чтобы задействовать все ядра для сетевого сервера.

Ни то ни другое не для I/O. Если эндпоинт медленный, потому что ждёт базу, воркер не поможет — узкое место это база, а loop вообще не был заблокирован.

worker_threads: настоящие потоки, изолированная память

worker_threads даёт настоящие потоки ОС внутри одного процесса Node, у каждого свой V8-изолят и свой event loop. Ты порождаешь поток со скриптом и передаёшь ему данные; он считает и шлёт результат назад.

// main.js
import { Worker } from "node:worker_threads";

function hashInWorker(password) {
  return new Promise((resolve, reject) => {
    const worker = new Worker("./hash-worker.js", { workerData: password });
    worker.on("message", resolve);
    worker.on("error", reject);
    worker.on("exit", (code) => {
      if (code !== 0) reject(new Error(`worker exited ${code}`));
    });
  });
}

// hash-worker.js
import { workerData, parentPort } from "node:worker_threads";
import bcrypt from "bcrypt";
parentPort.postMessage(bcrypt.hashSync(workerData, 12)); // CPU-работа, вне главного loop

Всё определяют два факта. Первый: память изолирована. Воркер не делит переменные с родителем; каждая полезная нагрузка postMessage структурно клонируется, что стоит CPU и памяти пропорционально размеру — отправка 50-мегабайтного буфера так копирует 50 МБ. Для крупных бинарных данных есть два выхода: передать ArrayBuffer в transfer-листе сообщения (zero-copy — владение переходит, отправитель больше не может к нему обращаться) или поделиться им по-настоящему через SharedArrayBuffer (буфер в общей памяти, видимый всем потокам процесса) плюс Atomics для координации, так что несколько потоков читают и пишут одни и те же байты вообще без клонирования.

const ab = new ArrayBuffer(64 * 1024 * 1024);
worker.postMessage({ ab }, [ab]); // transfer-лист → zero-copy; ab здесь теперь detached

Второй: порождение воркера стоит реальных денег — новый поток, новый V8-изолят, мегабайты RAM и десятки миллисекунд старта. Порождать по одному на запрос — антипаттерн, который часто стоит дороже, чем работа, которую он выгружает. Правильная форма — пул: фиксированный набор долгоживущих воркеров, размером примерно по числу ядер CPU, которые тянут задачи из очереди. Библиотеки вроде piscina это реализуют; правило большого пальца — размер пула ≈ os.availableParallelism(), потому что больше потоков, чем ядер, только дёргает планировщик впустую.

cluster: много процессов, один общий сокет

cluster решает другую проблему: масштабирование сетевого сервера по всем ядрам. Главный процесс форкает N рабочих процессов, и все они делят один слушающий сокет — входящие соединения распределяются между воркерами. На не-Windows-платформах схема по умолчанию — round-robin (каждое новое соединение отдаётся следующему воркеру по кругу) в главном процессе; иначе ОС распределяет через SO_REUSEPORT. Каждый воркер — это полноценный процесс Node со своей памятью и своим event loop, так что восемь воркеров честно используют восемь ядер для обработки запросов.

import cluster from "node:cluster";
import { availableParallelism } from "node:os";
import http from "node:http";

if (cluster.isPrimary) {
  for (let i = 0; i < availableParallelism(); i++) cluster.fork();
  cluster.on("exit", (worker) => cluster.fork()); // заменить умерший воркер
} else {
  http.createServer((req, res) => res.end("handled by " + process.pid)).listen(3000);
}

Определяющее ограничение: процессы не делят память. Сессионная мапа в памяти, локальный счётчик rate-limit или кэш уровня процесса существуют в каждом воркере отдельно — запрос, обработанный воркером A, не увидит состояние, которое выставил воркер B. Фикс — вынести общее состояние во внешнее хранилище (Redis, базу) и считать каждый воркер stateless. В современных деплоях cluster часто вытесняется запуском N реплик-контейнеров за балансировщиком (или процесс-менеджером вроде PM2), что даёт тот же параллелизм плюс рестарт, выкатку и масштабирование между хостами — дисциплина «stateless-процессы, общее хранилище» применима в любом случае.

Выбор и режимы отказа

Дерево решений короткое. Работа I/O-bound? Не делай ничего — она уже async, и добавление потоков или процессов лишь добавит накладных расходов. Это CPU-работа, которой нужны общие или крупные данные в процессе? Пул worker_threads. Это масштабирование stateless-сетевого сервера по ядрам? cluster или реплики.

// Запуленные, не на каждый запрос — piscina держит размер ≈ ядра и переиспользует воркеры
import Piscina from "piscina";
const pool = new Piscina({ filename: "./resize-worker.js" });
app.post("/thumb", async (req, res) => {
  const out = await pool.run(req.body); // CPU-работа бежит вне главного loop, на переиспользованном потоке
  res.end(out);
});

Повторяются два режима отказа. Первый: синхронная CPU-работа на главном потоке. Это и есть хук — машина, простаивающая на 30%, с p99 в 6 секунд, потому что один поток тащит всю тяжесть, пока семь ядер простаивают. Симптом: всплески лага event loop, таймауты и падающие health-check под нагрузкой, исчезающие при низком трафике. Фикс: выгрузить CPU-работу в пул воркеров. Второй: забыть, что воркеры cluster не делят память. Ты выкатываешь сессии в памяти или локальный кэш, в dev работает (один процесс), а в проде с восемью воркерами сессия юзера «случайно» пропадает каждый восьмой запрос, потому что его обработал другой воркер. Фикс: вынести это состояние в общее хранилище и держать воркеры stateless.