რა განსხვავებაა Node.js-ში blocking და non-blocking ოპერაციებს შორის?

Question

IT Interview Practice · Accepted Answer

**ბლოკირებადი** ოპერაციები სინქრონულად სრულდება და იკავებს ერთადერთ JavaScript ნაკადს (thread) დასრულებამდე — ამ დროს სხვა ვერაფერი მუშაობს. **არაბლოკირებადი** ოპერაციები იწყებს სამუშაოს, მაშინვე ბრუნდება და შედეგს მოგვიანებით აწვდის callback-ის, Promise-ის ან event-ის მეშვეობით, ასე რომ ნაკადი თავისუფალი რჩება სხვა საქმისთვის.

## რატომ არის Node ერთნაკადიანი და მაინც არაბლოკირებადი

შენი JavaScript მუშაობს **ერთ** ნაკადზე, რომელსაც **event loop** მართავს. I/O (ფაილები, ქსელი, DNS) დელეგირებულია **libuv**-ზე, რომელიც შიგნით იყენებს OS-ის ასინქრონულ საშუალებებს და პატარა **thread pool**-ს. სანამ ეს სამუშაო ნაკადის გარეთ მიმდინარეობს, event loop აგრძელებს სხვა callback-ების დამუშავებას. როცა I/O სრულდება, მისი callback რიგში დგება და სრულდება.

```js
const fs = require("node:fs");

// ბლოკირებადი: მთელი პროცესი აქ ელოდება; სხვა არცერთი მოთხოვნა არ მომსახურდება.
const data = fs.readFileSync("big.json");
console.log("done reading");

// არაბლოკირებადი: მაშინვე ბრუნდება; callback მუშაობს, როცა I/O სრულდება.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## ბლოკირებადი vs არაბლოკირებადი

| | Blocking | Non-blocking |
|---|---|---|
| API-ის სტილი | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| ნაკადი | იკავებს event loop-ს | ათავისუფლებს event loop-ს |
| გამტარუნარიანობა | ერთი მოთხოვნა ერთ დროს | ბევრი ერთდროული მოთხოვნა |
| როდის გამოვიყენოთ | გაშვების/CLI სკრიპტები | სერვერები, მოთხოვნის დამმუშავებლები |

## ხაფანგი: CPU-ზე დამოკიდებული სამუშაო მაინც ბლოკავს

არაბლოკირებადი მხოლოდ **I/O**-ს შემთხვევაში ეხმარება. მძიმე სინქრონული გამოთვლა (უზარმაზარი payload-ის JSON-ის დამუშავება, კრიპტოგრაფია, სურათის ზომის შეცვლა, მჭიდრო ციკლი) ბლოკავს event loop-ს თვით `async` ფუნქციის შიგნითაც, რადგან თავად CPU-ს სამუშაო JS ნაკადზე მუშაობს.

```js
// ბლოკავს event loop-ს მთელი ციკლის განმავლობაში, თუმცა "async"-ია.
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // CPU-ზე დამოკიდებული, სინქრონული
  return x;
}
```

გადაიტანე CPU-ზე დამოკიდებული სამუშაო **`worker_threads`**-ში, child process-ში ან queue-ში, რომ event loop მოქნილი დარჩეს:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // მუშაობს ცალკე ნაკადზე
```

## პრაქტიკული წესები

- სერვერზე მოთხოვნის დამმუშავებლის შიგნით არასდროს გამოიძახო `*Sync` API.
- გამოიყენე ასინქრონული I/O ყველგან ცხელ გზაზე (hot path).
- CPU-ზე მძიმე სამუშაო გაიტანე მთავარი ნაკადის გარეთ.
- ფრთხილად შემთხვევით ბლოკირებაზე: დიდი `JSON.parse`, სინქრონული კრიპტოგრაფია, catastrophic backtracking-ის მქონე regex-ები.

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

Node-ის წარმადობის მოდელი მთლიანად დამოკიდებულია ერთადერთი event loop ნაკადის თავისუფლად შენარჩუნებაზე. ერთი გზააბნეული ბლოკირებადი გამოძახება — ერთი `readFileSync`, ერთი სინქრონული hash, ერთი ნელი regex — აჩერებს **ყველა** ერთდროულ მოთხოვნას, არა მხოლოდ იმას, ვინც ის გამოიწვია. იმის გაგება, თუ რა ბლოკავს და რა არა, არის განსხვავება იმ სერვერს შორის, რომელიც ათასობით კავშირზე მასშტაბირდება, და იმ სერვერს შორის, რომელიც დატვირთვის ქვეშ იყინება.

	Blocking	Non-blocking
API-ის სტილი	`*Sync` (`readFileSync`)	callback / Promise / `async`
ნაკადი	იკავებს event loop-ს	ათავისუფლებს event loop-ს
გამტარუნარიანობა	ერთი მოთხოვნა ერთ დროს	ბევრი ერთდროული მოთხოვნა
როდის გამოვიყენოთ	გაშვების/CLI სკრიპტები	სერვერები, მოთხოვნის დამმუშავებლები

რატომ არის Node ერთნაკადიანი და მაინც არაბლოკირებადი

ბლოკირებადი vs არაბლოკირებადი

ხაფანგი: CPU-ზე დამოკიდებული სამუშაო მაინც ბლოკავს

პრაქტიკული წესები

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

დაკავშირებული კითხვები