Thư Viện Câu Hỏi Phỏng Vấ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).

Bản chất của thuật toán Merge Sort theo tư tưởng Divide and Conquer

Merge Sort là một ví dụ kinh điển của mô hình Divide and Conquer gồm ba bước cốt lõi:

Tư tưởng Divide and Conquer trong thuật toán Strassen

Thuật toán nhân ma trận thông thường yêu cầu 3 vòng lặp lồng nhau với độ phức tạp thời gian là O(n^3). Volker Strassen nhận ra rằng có thể áp dụng tư tưởng Divide and Conquer để giảm số phép nhân ma trận con từ 8 xuống còn 7.

Phân tích bài toán

Một lỗi phổ biến của lập trình viên cấp độ Junior khi kiểm tra BST là chỉ so sánh giá trị của node hiện tại với node con trái và node con phải trực tiếp của nó. Cách tiếp cận này sai vì một node ở cây con bên phải có thể nhỏ hơn giá trị của node gốc.

Tư tưởng chia để trị ẩn trong Fenwick Tree

Fenwick Tree biểu diễn một mảng tuyến tính thông qua các khoảng tổng dựa trên hệ cơ số 2 (Binary Representation). Thay vì chia đôi mảng một cách đối xứng như Merge Sort hay Binary Search, Fenwick Tree chia mảng thành các đoạn có kích thước tương ứng với giá trị của bit 1 thấp nhất (Lowest Set Bit - LSB).

Phân tích bài toán Maximum Subarray

Cho một mảng chứa cả số âm và số dương, tìm đoạn con liên tiếp sao cho tổng các phần tử trong đoạn đó là lớn nhất.

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.

Bản chất vấn đề

Vấn đề Fragile Base Class xảy ra khi một lớp cơ sở (Base Class) được thay đổi, và sự thay đổi này vô tình làm hỏng hoặc thay đổi hành vi của các lớp dẫn xuất (Derived Classes) phụ thuộc vào nó. Khi hệ thống có hệ thống kế thừa quá sâu, việc bảo trì trở nên cực kỳ rủi ro vì lập trình viên không thể lường trước được tác động lan truyền.

Bản chất vấn đề

Liskov Substitution Principle (LSP) phát biểu rằng: Các đối tượng của lớp con phải có khả năng thay thế các đối tượng của lớp cha mà không làm thay đổi tính đúng đắn của chương trình. Khi lớp con ném ra ngoại lệ như UnsupportedOperationException cho một hành vi kế thừa từ lớp cha, nó đã vi phạm LSP.