Mục lục nội dung

Giới thiệu

Node.js nổi tiếng với mô hình I/O không chặn, cho phép xử lý hàng nghìn kết nối đồng thời trên một luồng duy nhất. Tuy nhiên, khi ứng dụng phải thực hiện các tác vụ CPU‑bound (tính toán phức tạp, mã hoá, xử lý ảnh, v.v.) mô hình đơn luồng sẽ trở thành nút thắt, gây event loop bị block và làm giảm tốc độ phản hồi xuống mức không chấp nhận được.

Bài viết này sẽ phân tích sâu cách khai thác Cluster và Worker Threads – hai cơ chế tích hợp sẵn trong Node.js – để tận dụng đa lõi CPU, đồng thời đưa ra các best practices và cảnh báo thực tiễn khi triển khai trong môi trường production.

1. Node.js và giới hạn của mô hình đơn luồng

Mô hình event‑loop của Node.js cho phép thực thi các hàm bất đồng bộ (I/O) mà không cần tạo thêm luồng. Khi một hàm đồng bộ tiêu tốn thời gian CPU (ví dụ: vòng lặp tính toán lớn), event‑loop sẽ không thể tiếp nhận các sự kiện mới cho đến khi hàm đó hoàn thành. Kết quả là:

  • Thời gian phản hồi tăng đáng kể.
  • Người dùng gặp hiện tượng "treo" (timeout).
  • CPU không được khai thác tối đa vì chỉ một lõi đang chạy.

Để giải quyết, chúng ta cần đưa các tác vụ CPU‑bound ra khỏi luồng chính, hoặc tạo nhiều tiến trình làm việc song song.

2. Sử dụng Cluster để mở rộng theo tiến trình

Module cluster cho phép tạo một master process và một hoặc nhiều worker process. Mỗi worker là một bản sao của ứng dụng Node.js, chạy trên một lõi CPU riêng biệt. Master chịu trách nhiệm phân phối các kết nối tới các worker (thông qua round‑robin hoặc hệ thống OS).

2.1. Kiến trúc cơ bản

Dưới đây là sơ đồ luồng:

+-------------------+        +-------------------+
|   Master Process  | ----> |   Worker #1       |
| (listen on port) | ----> |   Worker #2       |
|                   | ----> |   ...             |
+-------------------+        +-------------------+

Master không thực hiện bất kỳ logic nghiệp vụ nào, chỉ quản lý vòng đời của worker.

2.2. Ví dụ thực tế: HTTP server đa tiến trình

Đoạn code dưới đây khởi tạo một server HTTP đơn giản, sử dụng cluster để tạo số worker bằng số lõi CPU hiện có.


const cluster = require('cluster');
const os = require('os');
const http = require('http');

if (cluster.isMaster) {
  const cpuCount = os.cpus().length;
  console.log(`Master process ${process.pid} is running`);
  console.log(`Forking ${cpuCount} workers`);

  // Fork workers.
  for (let i = 0; i < cpuCount; i++) {
    cluster.fork();
  }

  // Khi một worker chết, tự động tạo lại.
  cluster.on('exit', (worker, code, signal) => {
    console.log(`Worker ${worker.process.pid} died. Forking a new worker...`);
    cluster.fork();
  });
} else {
  // Worker processes share the same server port.
  http.createServer((req, res) => {
    // Giả lập một tác vụ CPU‑bound nhẹ.
    let sum = 0;
    for (let i = 0; i < 1e6; i++) {
      sum += i;
    }
    res.writeHead(200);
    res.end(`Handled by worker ${process.pid}, sum=${sum}`);
  }).listen(3000, () => {
    console.log(`Worker ${process.pid} started and listening on port 3000`);
  });
}

Với mỗi yêu cầu đến localhost:3000, một worker ngẫu nhiên sẽ xử lý, cho phép tận dụng tối đa cpuCount lõi.

2.3. Các lưu ý khi dùng Cluster

  • Sticky sessions: Khi ứng dụng cần duy trì session (ví dụ WebSocket), cần cấu hình load balancer (nginx, HAProxy) để gắn kết client với cùng một worker.
  • Graceful shutdown: Trước khi dừng một worker, gửi tín hiệu SIGTERM, chờ các kết nối hiện tại hoàn thành, rồi mới kill.
  • Environment variables: Mỗi worker có thể nhận biến môi trường riêng (ví dụ WORKER_ID) để phân biệt log.
  • Memory leak: Vì mỗi worker là một process riêng, rò rỉ bộ nhớ trong một worker không ảnh hưởng tới các worker khác, nhưng vẫn cần giám sát RSS để tự động restart.

3. Worker Threads – đa luồng trong cùng một process

Node.js 10.5+ giới thiệu module worker_threads, cho phép tạo các thread chạy song song trong cùng một process. Khác với cluster, các worker thread chia sẻ bộ nhớ (được truyền qua MessageChannel hoặc SharedArrayBuffer), giúp giảm chi phí tạo process.

3.1. Khi nào nên dùng Worker Threads?

  • Tác vụ CPU‑bound cần truy cập nhanh tới dữ liệu chung (cache, cấu hình).
  • Không muốn mở quá nhiều cổng mạng (cluster tạo mỗi worker một server).
  • Cần truyền dữ liệu lớn giữa các luồng mà không sao chép (sử dụng SharedArrayBuffer).

3.2. Ví dụ thực tế: Tính số nguyên tố bằng Worker Thread

Đầu tiên, tạo file prime-worker.js để thực hiện tính toán.


// prime-worker.js
const { parentPort } = require('worker_threads');

function isPrime(num) {
  if (num < 2) return false;
  for (let i = 2; i * i <= num; i++) {
    if (num % i === 0) return false;
  }
  return true;
}

parentPort.on('message', (max) => {
  const primes = [];
  for (let i = 2; i <= max; i++) {
    if (isPrime(i)) primes.push(i);
  }
  // Gửi kết quả về main thread.
  parentPort.postMessage(primes);
});
</pre>

Sau đó, trong file chính app.js:

<pre>
// app.js
const { Worker } = require('worker_threads');

function computePrimes(max) {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./prime-worker.js');
    worker.once('message', resolve);
    worker.once('error', reject);
    worker.postMessage(max);
  });
}

(async () => {
  console.time('prime');
  const result = await computePrimes(1e5);
  console.timeEnd('prime');
  console.log(`Found ${result.length} primes`);
})();

Kết quả: tính toán các số nguyên tố tới 100.000 chỉ mất vài chục mili giây, trong khi nếu thực hiện trên luồng chính sẽ làm block event loop và gây chậm trễ cho các request khác.

3.3. Best practices cho Worker Threads

  • Giới hạn số thread: Không nên tạo quá nhiều thread; thường os.cpus().length là giới hạn hợp lý.
  • Reuse thread pool: Sử dụng thư viện như poolifier hoặc tự xây dựng pool để tránh chi phí tạo thread lặp lại.
  • Truyền dữ liệu nhẹ: Dùng postMessage với Transferable (ArrayBuffer) để tránh sao chép.
  • Xử lý lỗi: Lắng nghe sự kiện error và exit để tự động khởi tạo lại thread bị sập.

4. So sánh Cluster và Worker Threads

Tiêu chí Cluster Worker Threads
Mô hình Multiple processes (isolated memory) Multiple threads (shared memory)
Chi phí tạo Đắt hơn (fork) Nhẹ hơn
Khả năng chịu lỗi Isolated – một process chết không ảnh hưởng tới các process khác Thread crash có thể làm toàn bộ process sụp
Chia sẻ dữ liệu Phải dùng IPC (message, Redis, DB) SharedArrayBuffer, MessageChannel
Ứng dụng phù hợp Web server, micro‑service, cần tách biệt môi trường CPU‑bound tasks, tính toán, xử lý ảnh, mã hoá

Trong thực tế, nhiều dự án kết hợp cả hai: Cluster để mở rộng số tiến trình, mỗi tiến trình lại sử dụng Worker Threads để xử lý các tác vụ nặng.

5. Kiến trúc mẫu: API xử lý ảnh lớn

Giả sử chúng ta xây dựng một API nhận file ảnh, thực hiện resize, watermark và trả về URL. Quy trình:

  1. Client gửi request tới nginx (load balancer).
  2. nginx chuyển tới một worker của cluster (Node.js).
  3. Node.js nhận file, lưu tạm, sau đó tạo một Worker Thread để thực hiện resize & watermark (CPU‑bound).
  4. Kết quả được lưu vào Redis cache và S3 storage.
  5. Response trả về URL đã lưu.

Đây là mô hình “process + thread” giúp tối đa hoá tài nguyên CPU mà vẫn giữ được tính sẵn sàng cao.

6. Giám sát và tự động mở rộng

Để duy trì hiệu năng, cần:

  • Sử dụng PM2 hoặc systemd để quản lý lifecycle của master process.
  • Giám sát CPU, Memory, Event Loop Lag bằng prom-client và Grafana.
  • Thiết lập auto‑scale trên cloud (AWS EC2 Auto Scaling, Kubernetes) dựa trên metric CPU Utilization > 70%.

7. Những lỗi thường gặp và cách phòng tránh

7.1. Memory leak trong Worker Thread

Do các thread chia sẻ bộ nhớ, một biến toàn cục không được giải phóng sẽ tồn tại trong suốt vòng đời process. Giải pháp: luôn sử dụng worker.terminate() sau khi công việc xong, và tránh lưu trạng thái lâu dài trong thread.

7.2. Race condition khi truy cập SharedArrayBuffer

Nếu nhiều thread cùng ghi/đọc một vùng nhớ mà không đồng bộ, kết quả sẽ không xác định. Sử dụng Atomics để thực hiện các thao tác nguyên tử.

7.3. Độ trễ khi tạo quá nhiều worker

Mỗi lần new Worker() có chi phí khởi tạo (tải module, tạo thread). Thay vì tạo mới cho mỗi request, xây dựng pool thread và tái sử dụng.

Kết luận

Việc tối ưu tài nguyên CPU cho ứng dụng Node.js không chỉ là việc “thêm nhiều máy chủ” mà còn phải hiểu rõ cơ chế hoạt động bên trong runtime. Cluster giúp mở rộng theo tiến trình, tách biệt môi trường và tăng tính chịu lỗi; Worker Threads cho phép xử lý các tác vụ CPU‑bound một cách nhanh chóng mà không gây block event loop. Khi kết hợp hợp lý, chúng tạo thành một kiến trúc mạnh mẽ, đáp ứng yêu cầu cao về hiệu năng và độ tin cậy.

Để nắm vững toàn bộ kiến trúc backend từ cơ bản tới nâng cao, bao gồm cả cách áp dụng Cluster và Worker Threads trong dự án thực tế, bạn có thể Tham khảo khóa học "Lập trình Back-End với NodeJS Express" tại đây.