როგორ აკეთებთ Node.js ანგარიშის მასშტაბირებას რამდენიმე CPU-ზე?

Question

Accepted Answer

ერთი Node პროცესი იყენებს მხოლოდ **ერთ CPU ბირთვს** (მისი JS გაშვებულია ერთ ძაფზე). მანქანის ყველა ბირთვის გამოსაყენებლად, თქვენ აწეული ხართ **რამდენიმე Node პროცესი** — `cluster` მოდულის, პროცესის მმართველის, როგორც PM2, ან კონტეინერის ორქესტრაციის მეშვეობით — და დატვირთული ბალანსირება სთხოვნების შორის.

## პრობლემა

```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.
```

## The cluster module — fork worker processes

```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);
}
```

პირველადი პროცესი fork-ს გაძლევს ერთ მუშაკს ბირთვზე; ყველა მუშაკი იზიარებს იმავე პორტს, და შემომავალი კავშირები ნაწილდება მათ შორის — გამრავლებული throughput-ს. აღმასკომი მუშაკები შეიძლება ავტომატურად გადაირთო მდგრადობისთვის.

## პრაქტიკაში: გამოიყენეთ PM2 (cluster mode)

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

წარმოების აპლიკაციები ჩვეულებრივ იყენებენ **PM2** (ან მსგავსი) ხელით დაწერილი cluster კოდის ნაცვლად — იგი მართავს forking-ს, დატვირთული ბალანსირებას, ნულოვანი წყვილი перезагрузკას, მონიტორინგს და restarts-ს.

## ან მასშტაბირება კონტეინერებით/ორქესტრაციით

```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.
```

## კრიტიკული გაფრთხოება: statelessness

```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
```

მრავალი პროცესის მასშტაბირება მუშაობისთვის, თქვენი აპლიკაცია უნდა იყოს **stateless** — ნებისმიერი გაზიარებული state (სესიები, cache, რეალურ დროში კოორდინაცია) უნდა იყოს გარე store-ში, როგორიცაა Redis, პროცესის მეხსიერებაში არა.

## რატომ აქვს ეს მნიშვნელობა

ყველა CPU ბირთვის გამოყენება აუცილებელია Node სერვერის სრული წარმადობის მისაღებად — ერთი პროცესი ტოვებს მრავალი ბირთვიანი მანქანის უმეტეს ნაწილს უმოქმედო.

ვარიანტების ცოდნა (cluster მოდული, PM2 cluster mode, ან ერთი პროცესი-კონტეინერი ორქესტრაციით) და, საკრიტიკოდ, **statelessness მოთხოვნა** (გარე Redis-დაყრდნობილი სესიები/cache/რეალურ დროში, რადგან პროცესები არ იზიარებენ მეხსიერებას) ფუნდამენტალური არის Node-ის მასშტაბირებისთვის წარმოებაში.

ეს ჰორიზონტალური მასშტაბირება, statelessness-ის დაკომბინირებული, არის თუ როგორ ენიჭება Node აპლიკაციებს მაღალი ტრაფიკი საიმედოდ.