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

1. Khái niệm InnoDB Buffer Pool

• InnoDB Buffer Pool là một vùng nhớ RAM được cấp phát để lưu trữ các trang dữ liệu (Data Pages) và trang chỉ mục (Index Pages) thường xuyên được truy cập.
• Khi thực hiện câu lệnh SELECT hoặc UPDATE, MySQL sẽ kiểm tra xem dữ liệu có nằm trong Buffer Pool hay không. Nếu có (Buffer Pool Hit), dữ liệu được đọc trực tiếp từ RAM với tốc độ cực nhanh mà không cần đọc từ ổ đĩa (Disk I/O), vốn chậm hơn rất nhiều.

2. Dấu hiệu nhận biết hệ thống thiếu Buffer Pool

• Buffer Pool Hit Rate thấp: Tỷ lệ trúng cache thấp hơn mức an toàn (thường các hệ thống Production cần duy trì trên 95% hoặc 99%).
• High Disk I/O: Theo dõi qua hệ điều hành thấy thông số iowait cao, ổ đĩa (đặc biệt là ổ HDD hoặc SSD thông thường) luôn trong trạng thái đọc/ghi liên tục.
• Truy vấn chậm bất thường: Các truy vấn đơn giản không có Index hoặc bảng dữ liệu quá lớn khiến MySQL liên tục phải nạp trang mới vào RAM và đẩy các trang cũ ra (gọi là thuật toán thay thế LRU - Least Recently Used).

3. Cách kiểm tra và cấu hình cơ bản

Để kiểm tra tỷ lệ trúng Buffer Pool trong MySQL, có thể sử dụng câu lệnh:

1. Khái niệm ACID trong Transaction

Transaction (Giao dịch) là một tập hợp các câu lệnh SQL được thực thi như một khối thống nhất. Các tính chất ACID bao gồm:

1. Bản chất của Deadlock trong InnoDB

1. Phân biệt JOIN và Subquery

Để đảm bảo dữ liệu đầu vào luôn hợp lệ trong ASP.NET Core, chúng ta sử dụng cơ chế Model Validation dựa trên các Data Annotations hoặc Fluent Validation.

Routing là cơ chế định tuyến trong ASP.NET Core giúp ánh xạ các HTTP Request đến các endpoint cụ thể trong ứng dụng, thường là các Action phương thức bên trong Controller.

Logging là một phần không thể thiếu trong việc giám sát, gỡ lỗi và quản lý vận hành ứng dụng Enterprise. ASP.NET Core cung cấp sẵn một hệ thống Logging abstraction mạnh mẽ thông qua interface ILogger và ILogger.

Khi làm việc với ORM như Entity Framework Core, việc truy vấn dữ liệu có mối quan hệ (Relationships như One-to-Many, Many-to-Many) đòi hỏi lập trình viên phải hiểu rõ các chiến lược tải dữ liệu liên quan.

Extension Methods (Phương thức mở rộng) là một tính năng mạnh mẽ của ngôn ngữ C# cho phép lập trình viên thêm các phương thức mới vào các kiểu dữ liệu đã tồn tại mà không cần tạo lớp kế thừa mới, không cần biên dịch lại mã nguồn gốc của kiểu dữ liệu đó.

Trong Reactive Programming, khi một lỗi xảy ra trong một Observable, luồng dữ liệu sẽ bị kết thúc (terminate) ngay lập tức. Để ngăn chặn việc này, toán tử catchError cần được đặt ngay sau toán tử thực hiện tác vụ bất đồng bộ (như switchMap hoặc mergeMap) thay vì đặt ở cuối chuỗi. Việc đặt catchError bên trong phạm vi của toán tử xử lý sẽ giúp cô lập lỗi, cho phép luồng chính tiếp tục hoạt động mà không bị ngắt kết nối. Ví dụ: source$.pipe(switchMap(val => apiCall(val).pipe(catchError(err => of(fallbackValue))))) giúp đảm bảo nếu apiCall thất bại, chỉ có yêu cầu đó bị ảnh hưởng và trả về giá trị mặc định, thay vì làm chết toàn bộ Subscription.

Việc gọi thủ công unsubscribe() dễ dẫn đến sai sót nếu lập trình viên quên thực hiện trong các Hook như ngOnDestroy hoặc componentWillUnmount, gây ra Memory Leak. Toán tử takeUntil cho phép chúng ta khai báo một Observable 'notifier' (thường là một Subject). Khi notifier này phát ra giá trị, tất cả các Subscription liên kết sẽ tự động bị hủy. Cách tiếp cận này mang tính khai báo (declarative), giúp code sạch hơn, dễ bảo trì và đảm bảo tính nhất quán trong việc quản lý tài nguyên, đặc biệt khi một Component có nhiều Subscription cần được dọn dẹp cùng một lúc.

Toán tử exhaustMap hoạt động theo cơ chế: khi nhận được một giá trị từ nguồn, nó sẽ bắt đầu xử lý tác vụ đó và bỏ qua (ignore) tất cả các giá trị mới từ nguồn cho đến khi tác vụ hiện tại hoàn thành. Trong nghiệp vụ Enterprise, khi người dùng nhấn nút 'Submit' nhiều lần liên tiếp, exhaustMap đảm bảo rằng chỉ có yêu cầu đầu tiên được xử lý, các lần nhấn sau đó sẽ bị loại bỏ cho đến khi server phản hồi. Điều này giúp tránh tình trạng gửi trùng lặp dữ liệu (duplicate submission) mà không cần phải quản lý trạng thái 'isSubmitting' thủ công bằng biến boolean.

Toán tử map chỉ đơn thuần là biến đổi giá trị (giống như Array.prototype.map), nó trả về giá trị trực tiếp. Ngược lại, mergeMap được dùng để xử lý các tác vụ bất đồng bộ (Inner Observable), nó sẽ tự động subscribe vào Observable được trả về và 'flatten' (làm phẳng) kết quả vào luồng chính. Lỗi phổ biến của Junior là sử dụng map để gọi một hàm trả về Observable, dẫn đến việc nhận được một Observable lồng nhau (Observable<Observable>) thay vì giá trị thực tế. Để lấy dữ liệu từ các tác vụ bất đồng bộ, bắt buộc phải dùng các toán tử dạng *Map như mergeMap, switchMap hoặc concatMap.

AsyncSubject có đặc điểm chỉ phát ra giá trị cuối cùng của chuỗi dữ liệu sau khi Observable hoàn thành (complete). Trong kiến trúc Enterprise, nó rất hữu ích khi cần thực hiện một chuỗi các tác vụ khởi tạo (ví dụ: tải cấu hình, xác thực người dùng, lấy thông tin profile) và chỉ muốn thông báo cho các thành phần khác khi tất cả đã hoàn tất. Khi các thành phần khác subscribe vào AsyncSubject sau khi nó đã hoàn thành, chúng sẽ nhận được giá trị cuối cùng đó ngay lập tức. Lưu ý: Nếu AsyncSubject không được gọi complete(), nó sẽ không phát ra bất kỳ giá trị nào, đây là điểm cần kiểm soát chặt chẽ trong luồng logic.

Bản chất vấn đề

Rate Limiting là kỹ thuật kiểm soát tần suất yêu cầu (request) mà một client có thể gửi đến server trong một khoảng thời gian nhất định. Trong môi trường Enterprise, đây là lớp phòng thủ đầu tiên chống lại các cuộc tấn công Brute Force, DoS (Denial of Service) và ngăn chặn việc lạm dụng API (API abuse).