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

Phân tích cơ chế

1. Pessimistic Locking: Khóa bản ghi ngay khi bắt đầu đọc, ngăn cản các luồng khác truy cập cho đến khi giao dịch kết thúc. Phù hợp với môi trường tranh chấp dữ liệu cực cao.
2. Optimistic Locking: Không khóa dữ liệu. Khi cập nhật, hệ thống kiểm tra xem dữ liệu có bị thay đổi bởi luồng khác không (thông qua version hoặc timestamp). Nếu có, giao dịch sẽ bị từ chối hoặc thử lại.

Tại sao chọn Optimistic Locking

• Tăng khả năng mở rộng (Scalability): Không gây nghẽn cổ chai do không giữ khóa lâu.
• Phù hợp với kiến trúc phân tán: Trong Microservices, việc giữ khóa trên nhiều service là rất khó và dễ gây Deadlock.

Lưu ý thực chiến

Sử dụng Optimistic Locking khi tần suất xảy ra xung đột dữ liệu thấp. Nếu hệ thống có tần suất ghi cực cao vào cùng một bản ghi, hãy cân nhắc lại thiết kế kiến trúc thay vì chỉ dựa vào cơ chế khóa.

Định nghĩa

Một Class được coi là Thread-safe nếu nó hoạt động đúng đắn ngay cả khi được truy cập đồng thời bởi nhiều luồng mà không yêu cầu thêm bất kỳ sự phối hợp nào từ phía người sử dụng Class đó.

Trong mô hình Cache Aside, ứng dụng chịu trách nhiệm đọc và ghi dữ liệu giữa Cache và Database. TTL đóng vai trò là cơ chế an toàn cuối cùng (fail-safe) để đảm bảo dữ liệu không bị cũ mãi mãi.

Mặc dù Cache thường được coi là dữ liệu tạm thời, nhưng trong môi trường Enterprise, việc để mất toàn bộ Cache khi Redis khởi động lại (Cold Start) sẽ gây ra hiện tượng Cache Miss đồng loạt, dẫn đến Database bị sập do quá tải (thường gọi là hiệu ứng Thundering Herd).

Khi ứng dụng chạy trên nhiều Server (Scale-out), mỗi instance sẽ có một vùng nhớ In-memory riêng biệt. Nếu dữ liệu được lưu trong biến cục bộ (ví dụ: static variable), mỗi instance sẽ giữ một bản sao khác nhau.

Redis hoạt động dựa trên cơ chế Single-threaded Event Loop để xử lý các lệnh. Mọi lệnh gửi đến sẽ được xếp hàng và xử lý tuần tự.

Dữ liệu có tính biến động cao là những dữ liệu thay đổi liên tục theo thời gian thực (ví dụ: số dư tài khoản, lượt view video theo giây).

Bản chất vấn đề

Việc sử dụng Salt giúp chống lại Rainbow Table bằng cách tạo ra các giá trị băm duy nhất cho mỗi mật khẩu, ngay cả khi mật khẩu gốc giống nhau. Tuy nhiên, Salt không làm giảm tốc độ tính toán của kẻ tấn công khi chúng thực hiện Brute-force hoặc Dictionary Attack.

Giới hạn của HTTPS

HTTPS (TLS) chỉ bảo vệ dữ liệu khi đang truyền tải (Data in transit) trên đường truyền. Một khi dữ liệu đến được Service đích, nó sẽ được giải mã và lưu trữ trong bộ nhớ của Service đó.

Bản chất của Key Management

Thuật toán mã hóa như AES-256 đã được chứng minh là an toàn về mặt toán học. Điểm yếu của hệ thống thường nằm ở cách quản lý khóa (Key Lifecycle Management).

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

1. Encryption (Mã hóa): Mục tiêu là tính bảo mật (Confidentiality). Chỉ người có khóa giải mã mới đọc được nội dung.
2. Signing (Ký số): Mục tiêu là tính toàn vẹn (Integrity) và xác thực (Authenticity). Đảm bảo dữ liệu không bị thay đổi và xác nhận người gửi là ai.

Rủi ro khi nhầm lẫn

• Nếu bạn chỉ mã hóa mà không ký, kẻ tấn công có thể thay đổi nội dung mã hóa (Bit-flipping attack) mà hệ thống không phát hiện được.
• Nếu bạn chỉ ký mà không mã hóa, dữ liệu vẫn ở dạng rõ (Plaintext), kẻ tấn công có thể đọc được thông tin nhạy cảm.

Best Practice

Trong các hệ thống Enterprise, luôn áp dụng nguyên tắc 'Encrypt-then-Sign' hoặc sử dụng các chế độ mã hóa tích hợp xác thực như AES-GCM để đảm bảo cả hai yếu tố cùng lúc.

Rủi ro của Key Reuse

Active Health Check là cơ chế Load Balancer chủ động gửi các yêu cầu kiểm tra (như HTTP GET /health) tới Backend Server theo định kỳ để xác định trạng thái sống/chết. Nếu server không phản hồi đúng, nó sẽ bị loại khỏi danh sách cân bằng tải. Ngược lại, Passive Health Check không gửi yêu cầu kiểm tra định kỳ mà quan sát kết quả của các yêu cầu thực tế từ người dùng. Nếu một server trả về lỗi (ví dụ 5xx) vượt quá ngưỡng cho phép trong một khoảng thời gian, Load Balancer sẽ tạm thời đánh dấu server đó là không khả dụng. Sự kết hợp giữa cả hai giúp hệ thống vừa phát hiện sớm sự cố (Active) vừa đảm bảo tính linh hoạt khi có lỗi phát sinh trong quá trình vận hành thực tế (Passive).

Thuật toán Round Robin thuần túy phân phối yêu cầu theo kiểu xoay vòng đều đặn, giả định rằng mọi Backend Server đều có khả năng xử lý như nhau. Tuy nhiên, trong thực tế Enterprise, các server thường có cấu hình phần cứng khác nhau (CPU, RAM). Nếu sử dụng Round Robin, server yếu sẽ bị quá tải trong khi server mạnh lại nhàn rỗi. Weighted Round Robin giải quyết vấn đề này bằng cách gán trọng số (weight) cho mỗi server. Server có cấu hình mạnh hơn sẽ được gán trọng số cao hơn, từ đó nhận được nhiều yêu cầu hơn theo tỷ lệ tương ứng. Ví dụ: Server A (weight 3) và Server B (weight 1) sẽ nhận yêu cầu theo tỷ lệ 3:1, giúp tối ưu hóa hiệu suất tổng thể của cụm server.

Sticky Sessions buộc các yêu cầu từ cùng một Client phải đi tới cùng một Backend Server dựa trên Session ID hoặc Cookie. Điều này giúp duy trì trạng thái phiên làm việc (session state) của người dùng. Tuy nhiên, nếu một lượng lớn người dùng cùng truy cập vào một server cụ thể, server đó sẽ bị quá tải trong khi các server khác có thể bị bỏ trống, dẫn đến mất cân bằng tải nghiêm trọng. Để khắc phục, thay vì lưu trữ session tại bộ nhớ của Backend Server, kiến trúc Enterprise hiện đại thường sử dụng các giải pháp lưu trữ tập trung như Redis hoặc Memcached. Khi đó, bất kỳ server nào cũng có thể xử lý yêu cầu của người dùng mà không cần phụ thuộc vào việc kết nối với server cũ, cho phép Load Balancer phân phối tải một cách tự do và hiệu quả hơn.