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

Vai trò của Property Observers

Property Observers cho phép theo dõi và phản ứng với các thay đổi của giá trị thuộc tính. Trong MVVM, chúng thường được dùng để cập nhật giao diện (UI) ngay khi dữ liệu trong ViewModel thay đổi.

Nguyên nhân gây lỗi OOM

Việc tải trực tiếp ảnh có độ phân giải cao vào bộ nhớ (RAM) mà không qua xử lý sẽ khiến ứng dụng vượt quá giới hạn bộ nhớ cho phép của hệ điều hành.

Lợi ích của Extension

1. Tổ chức code: Giúp phân tách các nhóm chức năng (ví dụ: tách phần triển khai Protocol, phần xử lý logic, phần UI) giúp file code dễ đọc hơn.
2. Tính module hóa: Dễ dàng quản lý các đoạn code thực hiện các tác vụ riêng biệt mà không làm thay đổi cấu trúc của class chính.

Hạn chế cần lưu ý

1. Không thể thêm Stored Properties: Bạn không thể khai báo các biến lưu trữ dữ liệu trong Extension, chỉ có thể thêm Computed Properties.
2. Khó khăn trong việc Debug: Nếu lạm dụng quá nhiều file nhỏ, việc truy vết luồng thực thi (execution flow) có thể trở nên phức tạp hơn đối với các lập trình viên mới.
3. Overriding: Bạn không thể override các phương thức đã được định nghĩa trong class cha từ bên trong Extension.

Kinh nghiệm thực chiến

Nên sử dụng Extension để tuân thủ nguyên tắc Single Responsibility Principle (SRP). Ví dụ: một class ViewController có thể có các extension riêng biệt như ViewController+TableViewDataSource.swift và ViewController+Network.swift.

Phân biệt Serial và Concurrent

1. Serial Queue: Thực hiện các tác vụ tuần tự, chỉ một tác vụ được chạy tại một thời điểm. Đảm bảo tính thứ tự của dữ liệu.
2. Concurrent Queue: Cho phép thực hiện nhiều tác vụ cùng lúc. Hệ thống sẽ quyết định số lượng thread tùy thuộc vào tài nguyên phần cứng.

Race Condition là gì?

Race Condition xảy ra khi nhiều thread cùng truy cập và thay đổi một biến (shared resource) tại cùng một thời điểm, dẫn đến kết quả không dự đoán được.

Vấn đề với Completion Handlers

Việc sử dụng Completion Handlers dễ dẫn đến tình trạng Callback Hell (lồng ghép nhiều closure), khó quản lý lỗi và dễ gây ra lỗi Retain Cycle nếu không sử dụng [weak self] cẩn thận.

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.

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).

Khi bạn sử dụng một hàm (như YEAR(), DATE(), UPPER()) trực tiếp lên cột trong mệnh đề WHERE, MySQL không thể sử dụng Index của cột đó vì giá trị trong Index đã được lưu trữ ở dạng gốc, không phải dạng đã qua xử lý.

Covering Index là trường hợp mà tất cả các cột cần thiết cho một câu lệnh SELECT đều nằm trong cùng một Index. Khi đó, MySQL có thể lấy dữ liệu trực tiếp từ cấu trúc B-Tree của Index mà không cần thực hiện thao tác 'Bookmark Lookup' (truy cập vào bảng dữ liệu chính để lấy các cột còn thiếu).

Kiểu dữ liệu ENUM cho phép lưu trữ một tập hợp các giá trị định trước, giúp tiết kiệm không gian lưu trữ và đảm bảo tính toàn vẹn dữ liệu ở mức cơ bản.

Cả hai đều là công cụ quan trọng để phân tích kế hoạch thực thi truy vấn (Query Execution Plan).

Độ chọn lọc (selectivity) được tính bằng tỷ lệ số giá trị duy nhất (cardinality) trên tổng số dòng dữ liệu. Một cột có độ chọn lọc thấp (ví dụ: cột 'giới tính' chỉ có 2 giá trị) sẽ khiến Index không hiệu quả.