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

Question

Trong kiến trúc Microservices, tại sao việc sử dụng Circuit Breaker lại là giải pháp then chốt để duy trì tính sẵn sàng (Availability) khi một dịch vụ phụ thuộc bị treo?

Middle

Answer 1

Circuit Breaker là một mẫu thiết kế (design pattern) giúp ngăn chặn sự lan truyền lỗi trong hệ thống phân tán. Khi một dịch vụ gọi đến dịch vụ khác (thông qua HTTP hoặc gRPC) mà dịch vụ đó phản hồi chậm hoặc lỗi liên tục, Circuit Breaker sẽ chuyển trạng thái từ Closed sang Open. Khi ở trạng thái Open, mọi yêu cầu gọi đến dịch vụ đó sẽ bị chặn ngay lập tức (fail-fast), giúp dịch vụ gọi không bị treo do chờ đợi (blocking) và có thời gian để dịch vụ bị lỗi phục hồi. Điều này ngăn chặn hiện tượng Cascading Failure và bảo vệ tài nguyên hệ thống.

Answer 2

Graceful Shutdown là quá trình ứng dụng dừng hoạt động một cách có kiểm soát khi nhận được tín hiệu kết thúc (SIGTERM). Thay vì dừng đột ngột, ứng dụng sẽ: 1. Ngừng nhận các request mới từ Load Balancer. 2. Hoàn thành các request đang xử lý dở dang (in-flight requests). 3. Đóng các kết nối Database và Message Queue một cách an toàn. Nếu không có cơ chế này, các request đang xử lý sẽ bị ngắt giữa chừng, gây ra lỗi 5xx cho người dùng và có thể làm hỏng dữ liệu (data corruption) trong các giao dịch chưa hoàn tất.

Answer 3

Trong môi trường phân tán, việc gửi lại yêu cầu (retry) là không thể tránh khỏi do lỗi mạng. Idempotency đảm bảo rằng dù một hành động được thực hiện nhiều lần với cùng một tham số, kết quả cuối cùng trên hệ thống vẫn không thay đổi. Ví dụ, khi thanh toán, nếu client gửi request nhưng bị timeout, client sẽ retry. Nếu không có Idempotency Key, hệ thống có thể trừ tiền khách hàng hai lần. Giải pháp thực chiến là sử dụng Idempotency-Key trong header, lưu trữ key này vào Redis hoặc Database để kiểm tra xem request đã được xử lý thành công trước đó hay chưa.

Answer 4

Shadowing là kỹ thuật sao chép lưu lượng truy cập thực tế (live traffic) từ môi trường Production sang một môi trường thử nghiệm (staging/shadow) mà không làm ảnh hưởng đến phản hồi thực tế của người dùng. Kỹ thuật này cho phép kiểm tra cách hệ thống mới xử lý tải thực tế, phát hiện các lỗi tiềm ẩn về hiệu năng hoặc logic mà môi trường test thông thường không thể mô phỏng được. Điều này giúp giảm thiểu rủi ro khi thay đổi kiến trúc hoặc nâng cấp phiên bản, đảm bảo tính sẵn sàng cao khi chính thức thay thế phiên bản cũ.

Answer 5

Việc sử dụng unbounded pool khiến hệ thống cố gắng tạo ra vô hạn các tài nguyên (thread hoặc kết nối) khi lưu lượng tăng đột biến. Điều này dẫn đến cạn kiệt tài nguyên hệ điều hành (Memory, File Descriptors, CPU context switching). Khi tài nguyên cạn kiệt, hệ thống sẽ rơi vào trạng thái không thể phản hồi (unresponsive). Giải pháp Enterprise là sử dụng Bounded Pool với cơ chế hàng đợi (queue) có giới hạn và chiến lược từ chối (rejection policy) phù hợp, giúp hệ thống duy trì sự ổn định thay vì sụp đổ hoàn toàn.

Answer 6

Bản chất của Dead Letter Queue (DLQ)

Dead Letter Queue (DLQ) là một hàng đợi đặc biệt trong hệ thống Message Broker (như RabbitMQ, AWS SQS, Apache Kafka) dùng để lưu trữ các thông điệp (messages) không thể được xử lý hoặc tiêu thụ thành công bởi các Consumer sau một số lần thử lại nhất định.