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

Quorum là kỹ thuật quan trọng để điều chỉnh mức độ nhất quán trong các hệ thống phân tán.

Split-Brain xảy ra khi mạng bị chia cắt, khiến các node trong hệ thống không thể giao tiếp và tự coi mình là node chủ (Master), dẫn đến việc ghi dữ liệu vào nhiều nơi khác nhau.

Bản chất vấn đề

Khi Producer tạo ra dữ liệu nhanh hơn tốc độ xử lý của Consumer trong hệ thống bất đồng bộ, hàng đợi (Queue) sẽ bị đầy, dẫn đến cạn kiệt bộ nhớ (Out of Memory - OOM) hoặc sập hệ thống. Backpressure là cơ chế phản hồi ngược từ Consumer về cho Producer để tiết chế hoặc tạm dừng tốc độ sinh dữ liệu.

Khái niệm cốt lõi

• Thread-per-request Model: Mỗi HTTP request được xử lý trọn vẹn bởi một Thread riêng biệt trong suốt vòng đời của nó (Ví dụ: Spring Boot truyền thống với Tomcat).
• Event-Driven Non-blocking Model: Sử dụng một số ít các Thread (thường bằng số lượng CPU core) để xử lý các sự kiện thông qua Event Loop và Callback/Reactive (Ví dụ: Node.js, Netty, Spring WebFlux).

Tiêu chí lựa chọn kỹ thuật

1. I/O Bound vs CPU Bound:
   • Nếu ứng dụng chủ yếu chờ đợi I/O (truy vấn Database chậm, gọi API bên thứ ba): Event-Driven Non-blocking tối ưu hơn rất nhiều vì không lãng phí tài nguyên để cấp phát Stack cho hàng ngàn Thread đang đứng chờ.
   • Nếu ứng dụng thực hiện các thuật toán tính toán nặng, mã hóa, xử lý ảnh (CPU Bound): Thread-per-request hoặc kết hợp Thread Pool riêng là lựa chọn an toàn hơn để tránh làm nghẽn Event Loop.
2. Độ phức tạp khi Debug:
   • Mô hình Thread-per-request dễ debug hơn nhờ Stack Trace rõ ràng.
   • Mô hình Non-blocking có Stack Trace phức tạp hơn do tính chất bất đồng bộ qua nhiều callback hoặc reactive operator.

Lưu ý kinh nghiệm thực chiến

Với Java 21+, công nghệ Virtual Threads (Project Loom) đã thu hẹp khoảng cách này bằng cách cho phép viết code theo phong cách Thread-per-request đơn giản nhưng chạy trên nền tảng Non-blocking I/O ở tầng kernel, giúp đạt hiệu năng cao tương đương Event-Driven.

Các vấn đề đồng thời trong Caching phân tán

Khi nhiều tiến trình hoặc server cùng đọc và ghi vào một cache chung (như Redis), các hiện tượng sau thường xuyên xảy ra:

Bản chất Thread Starvation

Thread Starvation xảy ra khi một hoặc nhiều luồng không bao giờ nhận được CPU time hoặc tài nguyên cần thiết để chạy vì các luồng khác (thường có độ ưu tiên cao hơn hoặc chiếm giữ tài nguyên lâu hơn) đã chiếm dụng toàn bộ Thread Pool.

Định nghĩa và Bản chất

• Thread-safe Collections (Ví dụ: ConcurrentHashMap, CopyOnWriteArrayList trong Java): Là các cấu trúc dữ liệu được thiết kế sẵn để hỗ trợ truy cập đồng thời từ nhiều luồng mà không gây ra lỗi ConcurrentModificationException hoặc hỏng cấu trúc dữ liệu nội bộ.
• Explicit Synchronization (Ví dụ: từ khóa synchronized, ReentrantLock): Là cơ chế lập trình viên tự chủ động khóa toàn bộ một đoạn mã (Critical Section) để đảm bảo chỉ có duy nhất một luồng thực thi tại một thời điểm.

So sánh chi tiết

1. Mức độ chi tiết (Granularity):
   • Thread-safe Collections thường áp dụng cơ chế khóa ở mức độ phần tử hoặc phân đoạn (như khóa bucket trong ConcurrentHashMap), cho phép độ đồng thời (concurrency level) rất cao.
   • Explicit Synchronization nếu áp dụng sai cách (như khóa toàn bộ phương thức hoặc đối tượng lớn) sẽ làm giảm nghiêm trọng hiệu năng do các luồng phải xếp hàng chờ đợi.
2. Compound Operations (Thao tác kết hợp):
   • Bản thân ConcurrentHashMap thread-safe cho từng phương thức đơn lẻ (như get, put). Tuy nhiên, các thao tác kết hợp như Check-Then-Act (ví dụ: kiểm tra tồn tại rồi mới put) vẫn cần cơ chế đồng bộ hóa bên ngoài (như putIfAbsent) để tránh Race Condition.

Ví dụ minh họa lỗi kinh điển

ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<>();

// SAI: Vẫn có thể xảy ra Race Condition giữa check và put
if (!map.containsKey("key")) {
    map.put("key", 1);
}

// ĐÚNG: Sử dụng phương thức atomic của collection
map.putIfAbsent("key", 1);

Lưu ý kinh nghiệm thực chiến

Không được chủ quan rằng cứ dùng Concurrent Collection là an toàn tuyệt đối trước mọi Race Condition. Phải nắm rõ tính atomic của từng phương thức mà Collection đó cung cấp.

Để thiết kế một Logging và Monitoring Middleware đạt chuẩn Enterprise đáp ứng yêu cầu hiệu năng cao, chúng ta cần tuân thủ các nguyên tắc sau:

Việc quản lý Transaction đóng vai trò then chốt trong việc đảm bảo tính toàn vẹn dữ liệu (ACID) của hệ thống Enterprise.

Dependency Inversion Principle (DIP) là nền tảng cốt lõi trong kiến trúc phân tầng hiện đại (Clean Architecture / Hexagonal Architecture).

Compression Middleware chịu trách nhiệm nén HTTP Response trước khi trả về cho Client nhằm giảm dung lượng truyền tải qua mạng.

Bảo mật là yêu cầu tối quan trọng, tuy nhiên việc kiểm tra quyền hạn (Authorization) liên tục truy vấn Database ở mỗi Request sẽ tạo ra nút thắt cổ chai (Bottleneck) lớn về hiệu năng.

Khi một nghiệp vụ yêu cầu thay đổi dữ liệu trên nhiều Aggregate, chúng ta không được phép gộp chúng vào một transaction duy nhất vì sẽ làm giảm hiệu năng và vi phạm tính đóng gói. Giải pháp tiêu chuẩn là sử dụng Eventual Consistency thông qua Domain Events.

Anemic Domain Model là tình trạng các Entity chỉ chứa dữ liệu (properties) mà không chứa logic nghiệp vụ, trong khi logic được đẩy hết vào các Service. Điều này khiến Domain Model chỉ là một cấu trúc dữ liệu đơn thuần, làm mất đi tính đóng gói và khả năng kiểm soát trạng thái.

Shared Kernel là một phần của mô hình được chia sẻ giữa các Bounded Context. Tuy nhiên, nếu lạm dụng sẽ dẫn đến sự phụ thuộc chặt chẽ (tight coupling) giữa các service.