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

Định nghĩa Context Switching

Context Switching (Chuyển đổi ngữ cảnh) là quá trình hệ điều hành lưu lại trạng thái (Context, bao gồm giá trị thanh ghi, bộ đếm chương trình - Program Counter) của luồng đang chạy, và khôi phục trạng thái của luồng tiếp theo được lên lịch để chạy trên CPU.

Định nghĩa Callback Hell

Callback Hell (Địa ngục hàm gọi lại) là hiện tượng mã nguồn trở nên lồng nhau quá nhiều tầng các hàm callback (bất đồng bộ phụ thuộc lẫn nhau), tạo thành hình dạng giống kim tự tháp (Pyramid of Doom). Hiện tượng này thường xuất hiện khi xử lý các tác vụ tuần tự như: Kết nối DB -> Truy vấn dữ liệu -> Gọi API ngoài -> Xử lý file.

Trong kiến trúc SOA, một hệ thống lớn được chia thành hàng chục hoặc hàng trăm micro-services/Web services độc lập. Nếu mỗi dịch vụ đều phải tự kết nối về cơ sở dữ liệu trung tâm hoặc gọi một dịch vụ xác thực (Auth Service) riêng lẻ để kiểm tra quyền của người dùng cho mỗi request, hệ thống sẽ gặp vấn đề nghẽn cổ chai và độ trễ cao.

Trong môi trường phân tán của SOA, sự cố mạng hoặc sự chậm trễ từ một dịch vụ ngoại vi là điều không thể tránh khỏi. Nếu lập trình viên không áp dụng các biện pháp phòng vệ kỹ thuật, hệ thống sẽ dễ dàng rơi vào trạng thái tê liệt toàn diện.

Trong kiến trúc Service-Oriented Architecture (SOA), việc giám sát trạng thái của từng dịch vụ là cực kỳ quan trọng để đảm bảo tính sẵn sàng cao. Khi triển khai các Health Check, hệ thống thường sử dụng hai cơ chế chính:

Trong kiến trúc SOA, các dịch vụ thường xuyên gọi qua lại lẫn nhau. Nếu lập trình viên không chú ý đến tầng giao vận mạng, hiệu năng hệ thống sẽ sụt giảm mạnh do các nguyên nhân sau:

Trong hệ thống SOA, các nghiệp vụ như xuất báo cáo lớn, xử lý hình ảnh/video, hoặc đồng bộ dữ liệu hàng loạt thường mất nhiều thời gian (vài chục giây đến vài phút). Nếu xử lý đồng bộ qua HTTP Request, hệ thống sẽ gặp các vấn đề lớn như Gateway Timeout (HTTP 504), treo thread ở phía server và client mất kết nối giữa chừng.

Phân biệt Sharding và Replication

• Replication (Replica Set): Tập trung vào tính sẵn sàng cao (High Availability) và khả năng chịu lỗi (Fault Tolerance). Dữ liệu được sao chép từ Node chính (Primary) sang các Node phụ (Secondary). Nếu Primary gặp sự cố, hệ thống sẽ tự động bầu chọn (Election) một Secondary mới lên làm Primary.
• Sharding: Tập trung vào khả năng mở rộng theo chiều ngang (Horizontal Scaling). Dữ liệu được phân mảnh (Chunk) và lưu trữ trên nhiều Server (Shard) khác nhau để chia sẻ tải trọng ghi và lưu trữ.

Khi nào cần kết hợp cả hai?

Trong môi trường Enterprise, chỉ dùng Replication không giải quyết được bài toán dữ liệu quá lớn vượt quá dung lượng ổ cứng hoặc tải ghi quá cao. Ngược lại, chỉ dùng Sharding mà không có Replication sẽ khiến hệ thống mất dữ liệu nếu một Shard bị hỏng.

Bản chất của Shard Key

Shard Key là trường dữ liệu được MongoDB sử dụng để phân phối dữ liệu giữa các Shard. Nếu chọn Shard Key có độ biến thiên thấp (Low Cardinality), dữ liệu sẽ bị dồn vào một vài Shard cụ thể, gây ra hiện tượng 'Jumbo Chunks' và mất cân bằng tải (Imbalanced Cluster).

Cơ chế Eviction Policy

Khi bộ nhớ (Maxmemory) của Redis bị đầy, Redis cần giải phóng không gian để lưu trữ dữ liệu mới. Các chính sách Eviction (như allkeys-lru, volatile-lru, allkeys-random) sẽ quyết định Key nào bị xóa.

Định lý CAP

Định lý CAP phát biểu rằng một hệ thống phân tán chỉ có thể đảm bảo đồng thời 2 trong 3 yếu tố: Consistency (Tính nhất quán), Availability (Tính sẵn sàng), và Partition Tolerance (Khả năng chịu lỗi phân vùng).

Khi không thể sử dụng giao dịch ACID trên nhiều cơ sở dữ liệu, chúng ta áp dụng mô hình Saga Pattern để quản lý tính nhất quán. Saga là một chuỗi các giao dịch cục bộ (local transactions) được thực hiện tuần tự. Mỗi bước thực hiện thành công sẽ kích hoạt bước tiếp theo thông qua Event-driven architecture. Nếu một bước thất bại, hệ thống sẽ thực hiện các giao dịch bù (compensating transactions) để hoàn tác các thay đổi đã thực hiện trước đó nhằm đưa hệ thống về trạng thái nhất quán. Có hai cách tiếp cận chính: 1. Choreography: Các dịch vụ tự trao đổi sự kiện với nhau thông qua Message Broker. 2. Orchestration: Một dịch vụ trung tâm (Orchestrator) điều phối toàn bộ luồng giao dịch. Đối với Junior, cần hiểu rõ rằng tính nhất quán ở đây là Eventual Consistency (nhất quán cuối cùng) thay vì Strong Consistency.

Load Balancer đóng vai trò là điểm tiếp nhận yêu cầu duy nhất, giúp phân phối lưu lượng truy cập vào nhiều máy chủ phía sau (backend servers), từ đó tăng khả năng mở rộng và tính sẵn sàng cao (High Availability). 1. Layer 4 Load Balancing: Hoạt động ở tầng Transport (TCP/UDP). Nó dựa vào địa chỉ IP và cổng (port) để định tuyến gói tin mà không cần đọc nội dung gói tin. Ưu điểm là tốc độ cực nhanh và tiêu tốn ít tài nguyên. 2. Layer 7 Load Balancing: Hoạt động ở tầng Application (HTTP/HTTPS). Nó có thể kiểm tra nội dung yêu cầu (URL, Header, Cookie) để đưa ra quyết định định tuyến thông minh hơn. Ví dụ, điều hướng các yêu cầu liên quan đến hình ảnh tới một nhóm server riêng biệt. Trong thực tế, Layer 7 thường được sử dụng để tối ưu hóa trải nghiệm người dùng và bảo mật.

Việc lựa chọn phụ thuộc vào mục đích sử dụng và cấu trúc dữ liệu: 1. Block Storage: Chia dữ liệu thành các khối (blocks) có kích thước cố định. Hệ điều hành coi mỗi khối như một ổ cứng riêng biệt. Nó có độ trễ thấp, phù hợp cho cơ sở dữ liệu (Database) hoặc các ứng dụng yêu cầu hiệu năng đọc ghi cao. 2. Object Storage: Lưu trữ dữ liệu dưới dạng các đối tượng (objects) bao gồm dữ liệu gốc, metadata và định danh duy nhất. Nó không phân cấp thư mục truyền thống mà sử dụng flat namespace. Object Storage có khả năng mở rộng vô hạn, chi phí thấp, phù hợp cho lưu trữ dữ liệu tĩnh như ảnh, video, tệp sao lưu (backup). Junior cần nắm vững rằng Object Storage không phù hợp để chạy các ứng dụng yêu cầu thay đổi dữ liệu liên tục (random write) như hệ quản trị cơ sở dữ liệu.

Rate Limiting là kỹ thuật kiểm soát số lượng yêu cầu (requests) mà một người dùng hoặc một dịch vụ có thể gửi đến hệ thống trong một khoảng thời gian nhất định. Mục đích chính bao gồm: 1. Ngăn chặn tấn công DoS/DDoS: Hạn chế kẻ xấu làm quá tải hệ thống bằng cách gửi hàng triệu yêu cầu mỗi giây. 2. Bảo vệ tài nguyên: Đảm bảo các dịch vụ backend không bị cạn kiệt tài nguyên (CPU, RAM, Database connections). 3. Quản lý chi phí: Đối với các API trả phí, Rate Limiting giúp kiểm soát hạn mức sử dụng. Các thuật toán phổ biến bao gồm Token Bucket (cho phép bùng nổ lưu lượng tạm thời) và Fixed Window (đơn giản, dễ cài đặt). Việc triển khai Rate Limiting thường được thực hiện tại API Gateway hoặc Middleware của ứng dụng.