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

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.

Bản chất vấn đề và ngữ cảnh thực chiến

Trong các hệ thống phân tán áp dụng mô hình Availability và Partition Tolerance (AP) theo Định lý CAP, khi xảy ra sự cố mạng (Partition), các node khác nhau có thể tiếp nhận và ghi nhận các thao tác cập nhật dữ liệu một cách độc lập. Điều này dẫn đến hiện tượng xung đột dữ liệu (Data Conflict). Để giải quyết bài toán này ở tầng ứng dụng, lập trình viên cần sử dụng cơ chế Vector Clocks nhằm theo dõi lịch sử nhân quả (causality) của các bản ghi dữ liệu.

Bản chất vấn đề và ngữ cảnh thực chiến

Trong hệ thống tài chính và thanh toán điện tử, tính nhất quán tuyệt đối (Consistency) và tính toàn vẹn dữ liệu là yếu tố sống còn. Do đó, các kỹ sư hệ thống thường lựa chọn cơ sở dữ liệu thuộc nhóm CP (Consistency và Partition Tolerance) theo Định lý CAP, ví dụ như CockroachDB hoặc hệ thống sử dụng thuật toán đồng thuận Raft/Paxos (như etcd, ZooKeeper).

Bản chất vấn đề và ngữ cảnh thực chiến

Khi xây dựng ứng dụng web quy mô lớn, việc tích hợp Caching Layer (như Redis Cluster) giúp tăng cường độ sẵn sàng (Availability) và giảm tải cho Database. Tuy nhiên, việc duy trì tính nhất quán giữa Cache và Database trong hệ thống phân tán vi phạm hoặc làm phức tạp thêm các ràng buộc của Định lý CAP, đặc biệt khi xảy ra lỗi mạng giữa tầng ứng dụng, cache và database.

Bản chất cơ chế Token Authentication tại tầng CDN

Trong các hệ thống phân phối nội dung số lớn (như VOD hoặc Live Streaming), việc bảo vệ bản quyền tài nguyên là tối quan trọng. Thay vì chuyển yêu cầu xác thực về Origin Server cho mỗi tệp tin .ts hay .m4u, chúng ta cấu hình tầng Edge Server của CDN tự động kiểm tra tính hợp lệ của token.

Khái niệm cơ bản

Để tối ưu hóa hiệu năng mạng cho ứng dụng Enterprise, việc lựa chọn trung tâm dữ liệu phản hồi là yếu tố then chốt. Anycast Routing là công nghệ mạng cho phép nhiều máy chủ ở các vị trí địa lý khác nhau cùng quảng bá (advertise) chính xác cùng một địa chỉ IP công cộng (IP Address) thông qua giao thức định tuyến Border Gateway Protocol (BGP).

Bản chất hiện tượng Cache Stampede

Cache Stampede xảy ra khi một tài nguyên cực kỳ hot (ví dụ: trang chủ của một sự kiện Flash Sale) bị hết hạn cache (Expired) trên toàn bộ hệ thống CDN Edge nodes cùng một thời điểm. Hàng triệu request đồng thời đổ về Edge node, và vì tài nguyên không còn trong cache, tất cả các Edge nodes này đồng loạt chuyển tiếp (forward) request đó về Origin Server gây ra hiện tượng nghẽn cổ chai đột ngột.

Bản chất vấn đề

Trong kiến trúc Microservices kết hợp Domain-Driven Design, mỗi Bounded Context sở hữu một Database riêng biệt. Việc sử dụng Distributed Transactions (như Two-Phase Commit - 2PC) gây ra hiện tượng giảm hiệu năng nghiêm trọng, khóa tài nguyên và vi phạm tính cô lập của Microservices. Giải pháp tiêu chuẩn Enterprise là sử dụng mô hình Eventual Consistency thông qua Saga Pattern.