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

1. Vấn đề của Distributed Transactions (Two-Phase Commit - 2PC)

Trong kiến trúc Monolithic, một giao dịch cơ sở dữ liệu sử dụng ACID thông qua cơ chế Transaction cục bộ. Khi chuyển sang Microservices, mỗi service sở hữu một Database riêng biệt (Database-per-service). Để đảm bảo tính nhất quán dữ liệu qua nhiều service, lý thuyết có nhắc đến giao dịch phân tán Two-Phase Commit (2PC).

Bản chất của False Sharing

False Sharing là một hiện tượng suy giảm hiệu năng phần cứng xảy ra trong lập trình đa luồng trên các kiến trúc CPU đa nhân (Multi-core processors). Nó xảy ra khi hai hoặc nhiều luồng chạy trên các nhân CPU khác nhau cùng chỉnh sửa các biến độc lập nhưng lại nằm trên cùng một Cache Line (thường có kích thước 64 bytes trên các CPU hiện đại).

Khái niệm Thread Pool Queue Saturation

Thread Pool Queue Saturation xảy ra khi tốc độ các tác vụ (Tasks) gửi vào Thread Pool vượt quá tốc độ xử lý của các Worker Threads, khiến cho Blocking Queue đạt đến sức chứa tối đa (Maximum Capacity). Khi trạng thái này diễn ra, hệ thống sẽ rơi vào tình trạng quá tải nghiêm trọng, dẫn đến độ trễ (Latency) tăng cao, cạn kiệt bộ nhớ (OutOfMemoryError) hoặc sập toàn bộ ứng dụng.

Tác động của CPU-bound Task đối với Event Loop

Event Loop hoạt động dựa trên mô hình đơn luồng (Single-threaded event loop) kết hợp với xử lý I/O phi chặn (Non-blocking I/O). Luồng này chịu trách nhiệm nhận sự kiện, điều phối và thực thi các callback.

Bản chất vấn đề

Trong hệ thống SOA, mỗi dịch vụ sở hữu cơ sở dữ liệu riêng biệt. Khi một nghiệp vụ nghiệp vụ nghiệp vụ nghiệp nghiệp vụ (Business Transaction) đi qua nhiều dịch vụ, việc đảm bảo tính nhất quán là tối quan trọng.

Bản chất vấn đề

Trong mạng máy tính không đáng tin cậy, việc đảm bảo 'Exactly-once delivery' từ phía Producer là cực kỳ khó khăn, dẫn đến việc Message Broker thường cung cấp 'At-least-once delivery'. Điều này đồng nghĩa với việc Consumer có thể nhận được cùng một message nhiều lần. Nếu hệ thống không xử lý, việc lặp lại message (Ví dụ: trừ tiền tài khoản hai lần) sẽ gây hậu quả nghiêm trọng.

Bản chất vấn đề

Lỗi phổ biến của các lập trình viên khi mới tiếp cận SOA là chia nhỏ hệ thống dựa trên tầng kỹ thuật (UI Service, Business Service, Database Service) hoặc chia quá nhỏ theo từng bảng cơ sở dữ liệu. Kết quả là tạo ra một hệ thống Distributed Monolith: các dịch vụ phụ thuộc chéo lẫn nhau, gọi vòng lặp (Circular Dependency) và phải gọi database của nhau liên tục qua mạng.

Bản chất cơ chế Read Repair trong Apache Cassandra

Apache Cassandra là một cơ sở dữ liệu phân tán theo mô hình Masterless (P2P), thiết kế theo định lý AP (Availability và Partition Tolerance) trong định lý CAP, sử dụng cơ chế Eventual Consistency (Nhất quán cuối cùng). Để đảm bảo tính đồng bộ giữa các Replica mà không cần thông qua một Node điều phối trung tâm cho mọi thao tác ghi, Cassandra áp dụng cơ chế Read Repair.

Cơ chế Query Planner trong MongoDB

Khi một câu lệnh truy vấn (Query) được gửi đến MongoDB, nó không được thực thi trực tiếp ngay lập tức mà phải đi qua một bộ phận cốt lõi gọi là Query Planner (trước phiên bản 3.0 thường gọi là Classic Engine, hiện nay sử dụng trường phái tối ưu hóa dựa trên chi phí Cost-based Optimizer với công cụ lưu trữ WiredTiger).

Phân biệt Redis Sentinel và Redis Cluster

Cả Redis Sentinel và Redis Cluster đều là các giải pháp đảm bảo tính sẵn sàng cao (High Availability) cho Redis, nhưng chúng được thiết kế cho các mô hình kiến trúc và bài toán vận hành hoàn toàn khác nhau.

Khi xảy ra hiện tượng cạn kiệt Connection Pool, cần thực hiện các bước: 1. Giám sát: Kiểm tra metrics của Connection Pool (Active connections, Idle connections, Wait time). 2. Phân tích nguyên nhân: Kiểm tra các truy vấn chậm (Slow Queries) gây chiếm dụng kết nối lâu, hoặc lỗi rò rỉ kết nối (Connection Leak) do không đóng kết nối sau khi sử dụng. 3. Tối ưu hóa: Tối ưu hóa các câu lệnh SQL bằng cách đánh Index, sử dụng Read Replica để giảm tải cho Master, hoặc áp dụng Caching (Redis) để giảm số lượng truy vấn xuống Database. 4. Cấu hình: Điều chỉnh tham số pool size phù hợp với khả năng chịu tải của Database server và sử dụng cơ chế Timeout hợp lý để giải phóng kết nối bị treo.

Database Sharding là kỹ thuật phân mảnh cơ sở dữ liệu thành các phần nhỏ hơn và lưu trữ trên các server khác nhau để tăng khả năng mở rộng ngang (Horizontal Scaling). Vấn đề lớn nhất là Rebalancing dữ liệu khi thêm Shard mới. Để giải quyết, chúng ta nên sử dụng Consistent Hashing thay vì thuật toán Modulo truyền thống. Với Consistent Hashing, khi thêm một node mới, chỉ một phần nhỏ dữ liệu cần phải di chuyển thay vì toàn bộ dữ liệu. Ngoài ra, có thể sử dụng Virtual Nodes để phân bổ dữ liệu đồng đều hơn trên các vật lý server, tránh hiện tượng Hotspot.

Để thiết kế hệ thống Notification hiệu quả, cần áp dụng kiến trúc bất đồng bộ (Asynchronous Architecture): 1. Sử dụng Message Queue (như Kafka hoặc RabbitMQ) để tách biệt giữa dịch vụ phát sinh sự kiện và dịch vụ gửi thông báo. 2. Notification Worker: Xây dựng các worker chuyên biệt để tiêu thụ message từ queue và thực hiện gửi thông báo qua các Provider (Email, SMS, Push). 3. Throttling: Áp dụng cơ chế giới hạn tốc độ gửi để tránh bị các nhà cung cấp dịch vụ chặn do spam. 4. Retry Mechanism: Thiết kế cơ chế thử lại với chiến lược Exponential Backoff cho các thông báo gửi thất bại. Cách tiếp cận này đảm bảo hệ thống chính không bị block khi quá trình gửi thông báo gặp sự cố.

Để đảm bảo an toàn trong giao tiếp giữa các Microservices, nên áp dụng mô hình Zero Trust: 1. Sử dụng JWT (JSON Web Token) để truyền tải thông tin định danh người dùng và quyền hạn giữa các dịch vụ. 2. API Gateway: Đóng vai trò là điểm truy cập duy nhất, thực hiện xác thực token trước khi chuyển tiếp request vào hệ thống nội bộ. 3. Mutual TLS (mTLS): Thiết lập kết nối được mã hóa hai chiều giữa các dịch vụ để đảm bảo chỉ các dịch vụ được tin tưởng mới có thể giao tiếp với nhau. 4. Service Mesh: Sử dụng công cụ như Istio để quản lý chính sách bảo mật, kiểm soát truy cập (RBAC) và giám sát lưu lượng mạng một cách tập trung mà không cần thay đổi code của từng service.

Phân tích sự khác biệt

1. Cache Penetration (Xâm nhập Cache): Xảy ra khi ứng dụng liên tục truy vấn các dữ liệu không tồn tại trong cả Cache lẫn Database. Điều này khiến mỗi request đều xuyên qua Cache và đánh trực tiếp vào Database, gây quá tải hệ thống.