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

SSL Termination là quá trình Load Balancer thực hiện giải mã (decrypt) các yêu cầu HTTPS từ Client trước khi chuyển tiếp chúng tới Backend Server qua giao thức HTTP thông thường. Việc thực hiện bắt tay (handshake) SSL và mã hóa/giải mã tiêu tốn rất nhiều tài nguyên CPU. Nếu để mỗi Backend Server tự xử lý SSL, chúng sẽ mất đi một phần tài nguyên đáng kể vốn dành cho việc xử lý logic nghiệp vụ. Bằng cách tập trung việc giải mã tại Load Balancer (thường được tối ưu hóa bằng phần cứng hoặc các thư viện chuyên dụng), các Backend Server chỉ cần tập trung xử lý các yêu cầu HTTP, từ đó tăng cường khả năng phục vụ (throughput) và giảm độ trễ phản hồi cho người dùng cuối.

Connection Draining (hay còn gọi là Deregistration Delay) là cơ chế cho phép Load Balancer ngừng gửi các yêu cầu mới tới một Backend Server đang chuẩn bị tắt hoặc khởi động lại, nhưng vẫn cho phép server đó hoàn thành các yêu cầu đang xử lý dở dang. Nếu không có cơ chế này, khi một server bị ngắt kết nối đột ngột, các yêu cầu đang thực thi sẽ bị hủy bỏ (timeout), gây ra lỗi 502 Bad Gateway hoặc 504 Gateway Timeout cho người dùng. Việc cấu hình Connection Draining đảm bảo tính toàn vẹn của dữ liệu và trải nghiệm người dùng mượt mà trong quá trình bảo trì hoặc triển khai phiên bản mới (Deployment).

1. Định nghĩa

• Strict Consistency (Consistency trong CAP): Mọi thao tác đọc đều phải trả về giá trị của thao tác ghi gần nhất bất kể được thực hiện ở node nào.
• Eventual Consistency: Nếu không có thêm các bản cập nhật mới được thực hiện, tất cả các bản sao dữ liệu cuối cùng sẽ hội tụ về cùng một giá trị sau một khoảng thời gian.

2. Lý do lựa chọn mô hình Eventual Consistency

• Tối ưu hóa Availability: Giúp hệ thống luôn phản hồi nhanh chóng cho người dùng mà không cần chờ đợi quá trình khóa phân tán (Distributed Lock) hay đồng bộ hóa hoàn toàn giữa các trung tâm dữ liệu.
• Khả năng mở rộng (Scalability): Cho phép scale hệ thống theo chiều ngang (Horizontal Scaling) dễ dàng hơn rất nhiều bằng cách thêm các Read Replica.

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

Khi phỏng vấn ở mức độ Junior, bạn cần nhận thức được rằng người dùng cuối (End-user) thường không nhận ra độ trễ vài trăm mili-giây trong việc đồng bộ dữ liệu (ví dụ: số lượng like trên bài viết Facebook), nhưng họ sẽ rất khó chịu nếu website hiển thị lỗi timeout hoặc không thể truy cập do hệ thống cố gắng duy trì Strict Consistency trong lúc mạng chập chờn.

1. Cơ chế cấu hình Consistency Level

Các hệ thống NoSQL phân tán cho phép lập trình viên tinh chỉnh mức độ nhất quán thông qua các tham số đọc và ghi (ví dụ: QUORUM, ONE, ALL trong Apache Cassandra).

1. Bản chất của Stale Data trong hệ thống AP

Vì hệ thống ưu tiên tính sẵn sàng (Availability), khi mạng bị chia cắt, một client có thể đọc dữ liệu từ một node chưa nhận được bản cập nhật mới nhất, dẫn đến việc nhận về dữ liệu cũ (Stale Data).

1. Giải thích lý do không có hệ thống CA tuyệt đối

• Định lý CAP khẳng định rằng Network Partition (P) là một hiện tượng vật lý tất yếu trong thế giới thực (cáp quang đứt, switch hỏng, lỗi card mạng).
• Do đó, bạn không thể chọn loại bỏ P ra khỏi hệ thống phân tán. Hệ thống chỉ có thể lựa chọn giữa C và A khi P xảy ra. Một hệ thống tự nhận là CA thực chất chỉ là hệ thống chạy trên một node duy nhất (Single Node), không phải hệ thống phân tán.

2. Ý nghĩa đối với kỹ sư phần mềm

• Khi thiết kế kiến trúc hệ thống, câu hỏi không phải là "Làm thế nào để đạt cả C, A và P?" mà là "Khi xảy ra phân vùng mạng (P), hệ thống của chúng ta nên đánh đổi giữa C hay A?".
• Lập trình viên Junior cần tránh cạm bẫy quảng cáo của một số công nghệ tự nhận giải quyết được toàn diện mọi mặt của Định lý CAP mà không có sự đánh đổi về hiệu năng hoặc tính toàn vẹn.

3. Best Practice Enterprise

Luôn xây dựng các kịch bản dự phòng (Fallback mechanisms) và xử lý ngoại lệ (Error handling) ở tầng ứng dụng để đối phó với các tình huống mất kết nối mạng bất ngờ giữa các dịch vụ vi mô (Microservices).

Định lý CAP phát biểu rằng một hệ thống lưu trữ dữ liệu phân tán không thể đồng thời cung cấp nhiều hơn hai trong ba đảm bảo sau: Consistency (Tính nhất quán), Availability (Tính sẵn sàng), và Partition Tolerance (Khả năng chịu lỗi mạng).

Thread-safe là thuộc tính của mã nguồn đảm bảo rằng khi nhiều luồng cùng thực thi, trạng thái của chương trình vẫn đúng đắn. Reentrancy là một khái niệm cụ thể hơn: một hàm được gọi là Reentrant nếu nó có thể bị ngắt quãng giữa chừng và được gọi lại (ví dụ bởi một tín hiệu hoặc một luồng khác) mà không làm hỏng dữ liệu. Một hàm Reentrant không sử dụng các biến toàn cục hoặc tài nguyên chia sẻ không được bảo vệ. Sự khác biệt chính: Một hàm Thread-safe có thể sử dụng khóa (Lock) để bảo vệ dữ liệu, nhưng hàm Reentrant không cần khóa vì nó không chia sẻ trạng thái. Trong lập trình Enterprise, viết code Reentrant giúp giảm thiểu độ phức tạp của việc quản lý trạng thái và tránh các lỗi tranh chấp dữ liệu khó phát hiện.

Thread Local Storage (TLS) là một cơ chế lưu trữ dữ liệu mà mỗi luồng sở hữu một bản sao riêng biệt của biến đó. Khi một luồng truy cập vào biến ThreadLocal, nó không ảnh hưởng đến các luồng khác. Điều này cực kỳ hữu ích trong các ứng dụng Enterprise như: 1. Quản lý thông tin xác thực (User Context) trong các Request-per-thread model. 2. Quản lý kết nối Database (Transaction Context). Bằng cách sử dụng TLS, lập trình viên loại bỏ hoàn toàn nhu cầu sử dụng Mutex hay Synchronized cho các biến này, từ đó tăng hiệu năng hệ thống đáng kể. Lưu ý: Cần phải dọn dẹp (remove) dữ liệu trong ThreadLocal sau khi xử lý xong để tránh Memory Leak, đặc biệt khi sử dụng Thread Pool.

Livelock xảy ra khi hai hoặc nhiều luồng liên tục thay đổi trạng thái để đáp ứng với nhau nhưng không luồng nào có thể tiến triển công việc. Khác với Deadlock (nơi các luồng đứng yên chờ đợi tài nguyên), trong Livelock, các luồng vẫn đang hoạt động nhưng bị mắc kẹt trong một vòng lặp vô tận của việc phản ứng lại hành động của nhau. Ví dụ thực tế: Hai người đi ngược chiều nhau trong hành lang hẹp, cả hai cùng né sang trái rồi cùng né sang phải để tránh nhau, kết quả là cả hai vẫn chặn đường nhau. Cách khắc phục: Thêm yếu tố ngẫu nhiên (random backoff) vào logic xử lý để phá vỡ sự đồng bộ trong phản ứng của các luồng.

Immutable Objects là các đối tượng mà trạng thái không thể thay đổi sau khi khởi tạo. Trong môi trường đa luồng, vấn đề lớn nhất là Race Condition khi nhiều luồng cùng đọc và ghi vào một đối tượng. Nếu đối tượng là Immutable, nó mặc định là Thread-safe vì không có luồng nào có thể thay đổi trạng thái của nó. Lợi ích: 1. Không cần sử dụng khóa (Lock-free), giúp tăng hiệu năng. 2. Dễ dàng chia sẻ giữa các luồng mà không lo bị thay đổi ngoài ý muốn. 3. Giảm thiểu lỗi logic phức tạp. Trong các hệ thống Enterprise, việc ưu tiên sử dụng các cấu trúc dữ liệu bất biến (như các thư viện Immutable trong Java hoặc các kiểu dữ liệu Read-only trong C#) giúp code trở nên dễ kiểm thử và bảo trì hơn rất nhiều.

Việc nén dữ liệu tại tầng Edge (CDN) mang lại lợi ích vượt trội về hiệu năng nhờ các lý do sau:

Cơ chế 'Stale-While-Revalidate' (SWR) là một kỹ thuật trong HTTP Cache-Control giúp cải thiện đáng kể trải nghiệm người dùng:

Origin Shield là một lớp cache trung gian nằm giữa CDN Edge PoP và Origin Server. Vai trò của nó bao gồm:

Cache Key là định danh duy nhất để CDN lưu trữ và truy xuất dữ liệu. Việc xử lý Query String rất quan trọng: