Thư Viện Câu Hỏi Phỏng Vấn

Trong môi trường Microservices, việc duy trì tính nhất quán dữ liệu thường được giải quyết thông qua mô hình Saga Pattern. Thay vì sử dụng giao dịch ACID tập trung, chúng ta chia nhỏ giao dịch thành chuỗi các bước cục bộ. Mỗi bước sẽ cập nhật dữ liệu của một service và phát ra một sự kiện (Event) để kích hoạt bước tiếp theo. Nếu một bước thất bại, hệ thống sẽ thực hiện các giao dịch bù trừ (Compensating Transactions) để hoàn tác các thay đổi trước đó. Có hai cách tiếp cận chính: Choreography (các dịch vụ tự giao tiếp qua Message Broker như RabbitMQ hoặc Kafka) và Orchestration (một service điều phối trung tâm quản lý luồng xử lý). Việc sử dụng Saga giúp hệ thống đạt được tính nhất quán cuối cùng (Eventual Consistency) mà không làm giảm hiệu năng hệ thống.

Mặc dù cả Worker Threads và Child Processes đều giúp giải quyết vấn đề chặn Event Loop, Worker Threads mang lại ưu thế vượt trội về hiệu năng và tài nguyên. Child Processes tạo ra các tiến trình độc lập với bộ nhớ riêng, dẫn đến chi phí khởi tạo cao và tốn kém RAM. Ngược lại, Worker Threads chia sẻ cùng một không gian bộ nhớ trong cùng một tiến trình Node.js, giúp việc truyền dữ liệu giữa các thread nhanh hơn thông qua SharedArrayBuffer. Điều này giúp giảm đáng kể overhead khi quản lý tài nguyên hệ thống, đặc biệt trong các ứng dụng Enterprise cần xử lý song song các tác vụ như mã hóa, nén dữ liệu hoặc xử lý ảnh mà không làm ảnh hưởng đến luồng xử lý I/O chính.

Caching tại tầng Application giúp giảm tải cho Database và tăng tốc độ phản hồi. In-memory cache cục bộ (như biến global hoặc thư viện node-cache) chỉ tồn tại trong phạm vi của một tiến trình, dẫn đến vấn đề dữ liệu không đồng nhất khi ứng dụng chạy trên nhiều instance (Scale-out). Redis đóng vai trò là một Distributed Cache, cho phép tất cả các instance của ứng dụng truy cập vào cùng một nguồn dữ liệu duy nhất. Điều này đảm bảo tính nhất quán, hỗ trợ các cấu trúc dữ liệu phức tạp, khả năng lưu trữ bền vững (Persistence) và cơ chế TTL (Time-to-live) giúp tự động giải phóng bộ nhớ, từ đó tối ưu hóa hiệu năng cho các hệ thống có lưu lượng truy cập lớn.

ReDoS xảy ra khi một biểu thức chính quy (Regex) được thiết kế kém, dẫn đến thời gian xử lý tăng theo cấp số nhân (Catastrophic Backtracking) khi gặp các chuỗi đầu vào đặc biệt. Để ngăn chặn: 1. Tránh sử dụng các Regex phức tạp với các nhóm lồng nhau hoặc lặp lại không kiểm soát. 2. Sử dụng các thư viện kiểm tra Regex an toàn như safe-regex để phát hiện các mẫu có nguy cơ gây lỗi. 3. Luôn giới hạn độ dài của chuỗi đầu vào trước khi thực hiện kiểm tra. 4. Sử dụng các giải pháp thay thế như String.indexOf() hoặc các thư viện parser chuyên dụng nếu logic xử lý quá phức tạp. Việc kiểm soát chặt chẽ đầu vào ngay tại tầng Middleware là bước quan trọng nhất để bảo vệ ứng dụng.

Rate Limiting là kỹ thuật giới hạn số lượng yêu cầu từ một client trong một khoảng thời gian nhất định. Trong môi trường Enterprise, việc triển khai tại tầng code Node.js thường sử dụng các middleware như express-rate-limit kết hợp với Redis để lưu trữ trạng thái đếm số lượng request. Cách tiếp cận này cho phép đồng bộ hóa giới hạn trên nhiều instance của ứng dụng. Cấu trúc logic bao gồm: xác định định danh người dùng (thường là IP hoặc User ID), kiểm tra số lượng request hiện tại trong Redis, và trả về mã lỗi 429 (Too Many Requests) nếu vượt quá ngưỡng. Đối với các hệ thống lớn, giải pháp tối ưu hơn là đẩy việc Rate Limiting ra tầng Gateway hoặc Load Balancer như Nginx hoặc Kong để giảm tải cho ứng dụng Node.js.

Express.js hoạt động dựa trên một chuỗi các hàm Middleware. Mỗi middleware nhận vào 3 tham số: req (request), res (response), và next (hàm tiếp theo).

Trong phát triển dự án với Node.js, việc tối ưu hóa và quản lý tốt Express Middleware là vô cùng quan trọng để đảm bảo tính ổn định và hiệu năng của hệ thống. Dưới đây là các khía cạnh kỹ thuật cốt lõi:

Trong phát triển dự án với Node.js, việc tối ưu hóa và quản lý tốt Worker Threads là vô cùng quan trọng để đảm bảo tính ổn định và hiệu năng của hệ thống. Dưới đây là các khía cạnh kỹ thuật cốt lõi: