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

Khái niệm TTL (Time to Live)

TTL là khoảng thời gian định mức mà một bản ghi dữ liệu được phép tồn tại trong Cache trước khi hệ thống tự động xóa nó đi nhằm giải phóng bộ nhớ và đảm bảo tính tươi mới của dữ liệu.

Phân loại chi tiết

1. In-Memory Cache (Application Cache):

Nhận diện hiện tượng

Hiện tượng này được gọi là Cache Stampede (hoặc Cache Avalanche). Nó xảy ra khi một Key rất hot (được truy cập cực nhiều) đột ngột hết hạn (Expired) hoặc bị xóa, khiến hàng nghìn request cùng lúc đổ dồn vào kiểm tra Cache, nhận kết quả Cache Miss và đồng loạt truy vấn trực tiếp vào Database, gây quá tải và sập Database.

Bản chất của Định lý CAP

Định lý CAP phát biểu rằng một hệ thống lưu trữ dữ liệu phân tán (Distributed System) chỉ có thể đảm bảo tối đa hai trong ba yếu tố sau:

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

• Strong Consistency (Nhất quán mạnh): Ngay sau khi một thao tác ghi (Write) hoàn tất thành công, mọi thao tác đọc (Read) tiếp theo từ bất kỳ node nào cũng phải trả về giá trị mới được ghi đó.
• Eventual Consistency (Nhất quán cuối cùng): Nếu không có thêm các thao tác cập nhật nào được thực hiện, tất cả các replica cuối cùng sẽ hội tụ về cùng một giá trị sau một khoảng thời gian trễ nhất định (replication lag).

Ảnh hưởng đến logic lập trình ứng dụng

• Với Strong Consistency: Lập trình viên viết code rất đơn giản vì không phải lo lắng về việc dữ liệu cũ. Tuy nhiên, thời gian phản hồi (Latency) thường cao hơn do phải chờ đồng bộ hóa dữ liệu giữa các node.
• Với Eventual Consistency: Lập trình viên phải xử lý các bài toán phức tạp hơn ở tầng ứng dụng như:
  • Hiện tượng đọc lại dữ liệu cũ (Read-your-writes consistency).
  • Xung đột dữ liệu khi hai user cùng cập nhật một tài nguyên cùng lúc (Conflict Resolution) sử dụng cơ chế như Vector Clocks hoặc Last-Write-Wins (LWW).

Ví dụ thực tế

Khi xây dựng tính năng hiển thị số lượng lượt thích (Likes) trên một bài viết mạng xã hội, ta có thể dùng Eventual Consistency để tối ưu hiệu năng. Nhưng khi xây dựng tính năng trừ tiền trong ví điện tử, bắt buộc phải áp dụng Strong Consistency.

Bản chất kiến trúc RDBMS truyền thống

Các cơ sở dữ liệu quan hệ truyền thống ban đầu được thiết kế để chạy trên một máy chủ đơn lẻ (Single-node). Khi mở rộng sang mô hình phân tán hoặc High Availability (Primary-Replica), chúng ưu tiên tuân thủ các nguyên tắc ACID (Atomicity, Consistency, Isolation, Durability).

Bản chất hệ thống AP

Các cơ sở dữ liệu như Cassandra hay DynamoDB được thiết kế theo mô hình AP (Availability và Partition Tolerance) trong Định lý CAP. Chúng sử dụng cơ chế Masterless hoặc Multi-master, cho phép ghi dữ liệu đồng thời vào nhiều node mà không cần khóa toàn cục.

Câu trả lời trực diện

Không có hệ thống cơ sở dữ liệu phân tán nào trong thực tế đạt được chuẩn CA tuyệt đối. Một hệ thống đơn máy chủ (Standalone Server) có thể đạt được CA, nhưng đó không phải là hệ thống phân tán (Distributed System).

Nguyên nhân và Hậu quả

Khi phát triển các ứng dụng tích hợp trong môi trường SOA, lập trình viên Junior thường mắc lỗi không cấu hình thời gian chờ (Timeout) hoặc đặt thời gian chờ quá lớn cho các HTTP Client khi gọi các Web Services bên thứ ba hoặc dịch vụ nội bộ.

Bản chất vấn đề

Trong kiến trúc SOA truyền thống, các dịch vụ thường trao đổi thông tin thông qua giao thức SOAP sử dụng định dạng XML.

Thách thức trong hệ thống phân tán SOA

Khác với ứng dụng Monolithic nơi mọi log của một request nằm trên cùng một file hoặc một bảng cơ sở dữ liệu, kiến trúc SOA phân tách nghiệp vụ thành nhiều dịch vụ chạy trên các tiến trình hoặc máy chủ khác nhau. Khi một request từ client gửi vào, nó có thể gọi Service A, từ Service A gọi tiếp Service B và Service C.

Phân tích kiến trúc Service Granularity

Một trong những nguyên tắc của SOA là khả năng tái sử dụng dịch vụ. Tuy nhiên, lập trình viên Junior thường mắc sai lầm là chia nhỏ dịch vụ quá mức (Fine-grained services), ví dụ tạo riêng một dịch vụ chỉ để lấy tên khách hàng, một dịch vụ khác chỉ để lấy địa chỉ.

Tầm quan trọng của Exception Handling chuẩn hóa

Trong môi trường phân tán SOA, các ngoại lệ kỹ thuật (như lỗi kết nối Database, lỗi NullPointerException nội bộ của ngôn ngữ lập trình) nếu bị rò rỉ trực tiếp ra ngoài qua các Web Services sẽ gây ra hai vấn đề lớn:

Bản chất của Context Switching

Context Switching (Chuyển đổi ngữ cảnh) là quá trình CPU lưu lại trạng thái (context) của một Thread hoặc Process đang chạy, sau đó khôi phục trạng thái của một Thread hoặc Process khác để tiếp tục thực thi. Quá trình này bao gồm việc lưu các thanh ghi của CPU, con trỏ lệnh (Program Counter), và các thông tin quản lý bộ nhớ đếm.

1. Phân biệt khái niệm

• CPU-bound Task (Tác vụ nặng về tính toán): Là các tác vụ đòi hỏi sức mạnh xử lý thuần túy của CPU như mã hóa dữ liệu, nén file, xử lý thuật toán phức tạp, xử lý ảnh. Thời gian hoàn thành phụ thuộc trực tiếp vào tốc độ và số lượng Core của CPU.
• I/O-bound Task (Tác vụ chờ đợi vào Input/Output): Là các tác vụ mà ứng dụng phải dành phần lớn thời gian để chờ đợi phản hồi từ các hệ thống bên ngoài như truy vấn Database, gọi HTTP API, đọc ghi file từ ổ cứng, hoặc nhận dữ liệu qua mạng.

2. Mô hình xử lý tối ưu

• Đối với CPU-bound Task:
  • Mô hình tối ưu là Multithreading với số lượng Thread xấp xỉ bằng số lượng Core vật lý của CPU.
  • Việc tạo nhiều Thread hơn số Core sẽ gây ra hiện tượng Context Switching lãng phí vì CPU lúc nào cũng ở trạng thái 100% công suất.
• Đối với I/O-bound Task:
  • Mô hình tối ưu là Asynchronous / Event-driven Non-blocking (ví dụ như Node.js Event Loop, Java NIO, hoặc Async/Await trong C#).
  • Thay vì block một Thread trong lúc chờ đợi I/O phản hồi, hệ thống sẽ giải phóng Thread đó để xử lý các request khác, và chỉ quay lại xử lý tiếp tục khi có sự kiện I/O hoàn thành.

3. Kinh nghiệm thực chiến

Khi thiết kế API backend, Junior cần phân loại rõ ràng bản chất của từng API. Các API thực hiện báo cáo thống kê phức tạp (CPU-bound) nên được tách biệt ra các Worker riêng hoặc sử dụng Queue (như RabbitMQ, Kafka) để xử lý nền, tránh làm nghẽn Main Thread phục vụ các request HTTP thông thường.