Jak skalować aplikację Node.js na wielu procesorach?

Question

Accepted Answer

Jeden proces Node.js używa tylko **jednego rdzenia procesora** (jego kod JS działa na jednym wątku). Aby użyć wszystkich rdzeni na maszynie, uruchamiasz **wiele procesów Node.js** — poprzez moduł `cluster`, menedżer procesów jak PM2, lub orkiestrację kontenerów — i balansujesz obciążenie requestów między nimi.

## Problem

```text
A server with 8 CPU cores running ONE Node process → uses ~1 core, wastes 7.
Need multiple processes to utilize all cores and handle more concurrent load.
```

## Moduł cluster — rozwidlenie procesów worker

```js
import cluster from "cluster";
import { cpus } from "os";
import http from "http";

if (cluster.isPrimary) {
  const numCPUs = cpus().length;
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork(); // spawn one worker process per CPU core
  }
  cluster.on("exit", (worker) => {
    console.log(`worker ${worker.process.pid} died — restarting`);
    cluster.fork(); // restart a crashed worker (resilience)
  });
} else {
  // each worker runs the actual server; the OS load-balances connections across them
  http.createServer((req, res) => res.end("handled by " + process.pid)).listen(3000);
}
```

Proces główny rozwidla jeden worker na każdy rdzeń; wszystkie workery dzielą ten sam port, a połączenia przychodzące są rozdzielane między nimi — mnoży to przepustowość. Zaatakowane workery mogą być automatycznie restartowane dla niezawodności.

## W praktyce: używaj PM2 (cluster mode)

```bash
pm2 start app.js -i max   # run one instance per CPU core, with auto-restart & monitoring
```

Produkcyjne aplikacje zwykle używają **PM2** (lub podobnego) zamiast ręcznego pisania kodu cluster — obsługuje on rozwidlanie, balansowanie obciążenia, reloady bez przestojów, monitorowanie i restarty.

## Lub skaluj kontenerami/orkiestrację

```text
Run ONE Node process per container, and run MANY containers (Kubernetes, ECS),
with a load balancer in front. This is the modern cloud approach — simpler
per-process model, scaling handled by the orchestrator across machines.
```

## Krytyczne zastrzeżenie: bezstanowość

```text
Multiple processes don't share memory. So:
⚠️ Don't store sessions/state in process memory → use Redis/a shared store
⚠️ In-memory caches aren't shared across workers → use Redis for shared cache
⚠️ WebSocket connections live on one worker → use a Redis adapter to coordinate
```

Aby skalowanie wieloprocesowe działało, Twoja aplikacja musi być **bezstanowa** — każdy stan współdzielony (sesje, cache, koordynacja real-time) musi znajdować się w zewnętrznym magazynie jak Redis, nie w pamięci procesu.

## Dlaczego to ważne

Wykorzystanie wszystkich rdzeni procesora jest niezbędne, aby uzyskać pełną wydajność z serwera Node — jeden proces pozostawia większość maszyny wielordzeniowej bezczynna.

Znajomość opcji (moduł cluster, PM2 cluster mode, lub jeden proces na kontener z orkiestracją) i, co kluczowe, **wymóg bezstanowości** (sesje/cache/real-time wspierane przez Redis, ponieważ procesy nie dzielą pamięci) jest fundamentalne dla skalowania Node w produkcji.

To skalowanie poziome, w połączeniu z bezstanowością, to sposób, w jaki aplikacje Node obsługują duży ruch niezawodnie.