Đa luồng & đa tiến trình Node.js

Dù máy bạn có 8 hay 16 lõi CPU, code JavaScript của bạn - theo mặc định - chạy trên đúng một luồng. Ở khoá Cơ bản (bài Bất đồng bộ) ta đã thấy event loop khéo léo xen kẽ các việc chờ I/O để không đứng yên. Nhưng xen kẽ không phải là chạy cùng lúc: một phép tính toán nặng sẽ chiếm luôn luồng đó và làm đơ mọi thứ.

function fib(n) {
  return n < 2 ? n : fib(n - 1) + fib(n - 2);
}

console.log("bắt đầu");
console.log(fib(45));   // chạy vài giây tới chục giây (tuỳ máy) - CHIẾM luồng suốt thời gian đó
console.log("xong");     // phải đợi fib() xong mới in

// Trong lúc fib() chạy: click, request HTTP, setTimeout... đều bị treo.

• ▸JavaScript là ngôn ngữ đơn luồng: một luồng chạy code của bạn tại một thời điểm.
• ▸Event loop cho “đồng thời” (concurrency) khi CHỜ I/O - không phải “song song” (parallelism).
• ▸Việc CPU-bound nặng chặn cả luồng: trang web đơ, server ngừng nhận request.

Không phải việc gì cũng cần luồng. Câu hỏi quyết định: việc của bạn đang chờ (I/O-bound) hay đang tính (CPU-bound)?

• ▸I/O-bound = chủ yếu CHỜ → async/await giải quyết gọn, đừng vẽ rắn thêm chân.
• ▸CPU-bound = chủ yếu TÍNH → mới cần song song để tận dụng nhiều lõi CPU.
• ▸Chẩn đoán sai dẫn tới giải pháp thừa: thêm worker cho việc I/O hầu như vô ích.

Module node:worker_threads cho bạn tạo luồng thật. Đẩy việc nặng sang worker, luồng chính vẫn rảnh để phục vụ người dùng; xong việc, worker postMessage kết quả về.

import { Worker } from "node:worker_threads";

// "./fib-worker.js" tính theo thư mục bạn ĐỨNG khi chạy node - chạy từ thư mục chứa file
const worker = new Worker("./fib-worker.js", { workerData: 45 });

worker.on("message", (kq) => console.log("kết quả:", kq));
worker.on("error", (err) => console.error(err));
worker.on("exit", (code) => console.log("worker thoát:", code));

console.log("luồng chính chạy tiếp NGAY, không phải đợi worker...");

import { parentPort, workerData } from "node:worker_threads";

function fib(n) {
  return n < 2 ? n : fib(n - 1) + fib(n - 2);
}

parentPort.postMessage(fib(workerData));   // gửi kết quả về luồng chính

• ▸worker_threads tạo luồng thật, chạy song song trên lõi CPU khác.
• ▸Trao đổi qua message: workerData (gửi đi) và postMessage / on("message") (nhận về).
• ▸Luồng chính không bị chặn → trang/server vẫn phản hồi trong lúc worker tính.

Khi cần nhiều luồng cùng đọc/ghi một vùng nhớ (tránh copy dữ liệu lớn), dùng SharedArrayBuffer. Nhưng nhiều luồng ghi cùng lúc sẽ đua nhau - phải dùng Atomics để thao tác an toàn.

const sab = new SharedArrayBuffer(4);   // 4 byte dùng chung
const dem = new Int32Array(sab);        // nhìn vùng nhớ đó như mảng int32

// Gửi 'sab' cho worker (qua workerData/postMessage):
// CẢ HAI luồng cùng thấy MỘT vùng nhớ - đây là chia sẻ thật, không phải bản sao.

Atomics.add(dem, 0, 1);    // tăng an toàn (thao tác nguyên tử - không bị luồng khác xen giữa)
Atomics.load(dem, 0);      // đọc an toàn

// dem[0]++ thường: khi 2 luồng cùng chạy có thể MẤT cập nhật → tổng sai.

• ▸SharedArrayBuffer = vùng nhớ nhiều luồng cùng thấy (không copy).
• ▸Atomics.add/load/store... đảm bảo thao tác không bị xen giữa → tránh race condition.
• ▸Đổi lại, bạn phải tự lo đồng bộ - chỉ dùng khi thật cần hiệu năng.

Chia 8 việc CPU nặng cho nhiều worker. Kéo số worker lên và quan sát: thời gian co lại, nhưng không tuyến tính mãi - và không bao giờ ngắn hơn việc dài nhất.

• ▸Tăng tốc bị CHẶN TRÊN bởi số worker (4 worker → nhanh tối đa ~4×).
• ▸Tổng thời gian hoàn thành (makespan) không bao giờ ngắn hơn việc dài nhất - chia thế nào cũng vậy.
• ▸Trên máy thật còn trần số lõi CPU; vượt số lõi là tốn RAM, không nhanh thêm.

Đôi khi bạn cần hẳn tiến trình riêng - bộ nhớ tách biệt, V8 riêng, một cái sập không kéo cái khác theo. node:child_process tạo tiến trình con; node:cluster nhân bản server ra nhiều tiến trình cùng nghe một cổng.

import { fork } from "node:child_process";

const con = fork("./viec.js");          // tiến trình Node riêng, bộ nhớ riêng
con.send({ tac_vu: "xu-ly", dau_vao: 42 });
con.on("message", (m) => console.log("con trả lời:", m));

// viec.js:
//   process.on("message", (m) => process.send({ ket_qua: nangNhoc(m.dau_vao) }));

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

if (cluster.isPrimary) {
  for (let i = 0; i < availableParallelism(); i++) cluster.fork();   // mỗi lõi một con
} else {
  // Các con cùng .listen(3000): tiến trình CHÍNH nhận kết nối rồi chia
  // vòng tròn (round-robin) cho các con - mặc định trên Linux/macOS.
  createServer((req, res) => res.end(`Chào từ PID ${process.pid}`)).listen(3000);
}

• ▸child_process: tiến trình Node riêng, trao đổi qua send/on("message").
• ▸cluster: nhiều tiến trình cùng nghe một cổng - cách kinh điển để scale HTTP server đa lõi.
• ▸Tiến trình tách biệt = an toàn hơn khi sập, nhưng tốn RAM và không chia sẻ bộ nhớ trực tiếp.

Trình duyệt cũng có “worker”: Web Worker - anh em của Worker Threads. Đẩy việc nặng sang đó để giao diện không đơ. Lưu ý: Web Worker không chạm được DOM, chỉ tính toán rồi gửi kết quả về.

// trong trang (luồng chính - luồng vẽ giao diện)
const w = new Worker("./worker.js", { type: "module" });
w.postMessage(45);
w.onmessage = (e) => console.log("kết quả:", e.data);   // giao diện KHÔNG đơ

// worker.js - KHÔNG có document/window, chỉ tính toán
onmessage = (e) => {
  const kq = nangNhoc(e.data);   // nangNhoc = hàm tính nặng của mèo con (tự định nghĩa)
  postMessage(kq);
};

• ▸Web Worker giữ cho trang mượt khi có việc tính nặng (xử lý ảnh, dữ liệu lớn).
• ▸Chỉ luồng chính chạm DOM; worker tính xong thì postMessage về để cập nhật giao diện.
• ▸Cùng tư duy với Node: tách việc nặng ra luồng khác, trao đổi qua message.

Gói lại thành một bảng quyết định nhanh:

• ▸Tạo worker tốn chi phí: dùng POOL tái sử dụng, đừng tạo/huỷ liên tục.
• ▸Truyền dữ liệu lớn qua message tốn copy: cân nhắc transferable hoặc SharedArrayBuffer.
• ▸Nhiều worker hơn số lõi CPU → không nhanh thêm, còn tốn RAM.
• ▸Mặc định nên ưu tiên async; chỉ thêm luồng/tiến trình khi đo được nút thắt là CPU.