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

1. Bản chất của Eventual Consistency

Theo Định lý CAP, nhiều cơ sở dữ liệu NoSQL phân tán (như Apache Cassandra, Amazon DynamoDB) ưu tiên tính sẵn sàng (Availability) và chịu lỗi phân vùng (Partition Tolerance), chấp nhận hy sinh tính nhất quán tuyệt đối (Strong Consistency) tại thời điểm ghi dữ liệu.

1. Khái niệm Sharding

Sharding là kỹ thuật phân vùng dữ liệu theo chiều ngang (Horizontal Partitioning), trong đó các tập dữ liệu lớn được chia nhỏ và lưu trữ trên nhiều máy chủ (Shard servers) khác nhau nhằm tăng khả năng mở rộng (Scalability) và thông lượng xử lý (Throughput).

1. Nguyên nhân suy giảm hiệu năng

• Cơ chế B-Tree Index: Các index thông thường trong MongoDB được xây dựng dựa trên cấu trúc cây B-Tree, hoạt động tối ưu nhất khi tìm kiếm theo tiền tố từ trái sang phải (Left-to-Right Prefix Matching).
• Full Collection Scan: Khi sử dụng biểu thức chính quy (Regex) với wildcard ở đầu (ví dụ: /.*abc/ hoặc ^.*abc), cơ sở dữ liệu không thể tận dụng được Index có sẵn. Kết quả là database buộc phải thực hiện quét toàn bộ tập dữ liệu (Collection Scan - COLLSCAN), duyệt qua từng document một để khớp chuỗi, làm tăng thời gian phản hồi (Latency) và ngốn CPU.

2. Các phương pháp khắc phục tối ưu

• Left-anchored Regex: Luôn cố định ký tự đầu tiên nếu bắt buộc phải dùng regex (ví: /^abc/). Điều này cho phép B-Tree Index lọc trước các document bắt đầu bằng chữ 'abc'.
• Text Index: Sử dụng tính năng Text Search của MongoDB kết hợp với toán tử $text để tìm kiếm từ khóa, tuy nhiên cần lưu ý về dung lượng và chi phí duy trì Text Index.
• Tách trường dữ liệu: Nếu cần tìm kiếm theo tên miền phụ hoặc phần mở rộng, hãy tách chuỗi thành các trường riêng biệt (ví dụ: domain, subdomain) để query chính xác bằng trường giá trị thay vì dùng regex.
• Sử dụng External Search Engine: Đối với các hệ thống yêu cầu tìm kiếm mờ (Fuzzy Search) hoặc Full-text search phức tạp với lượng dữ liệu lớn, nên tích hợp các giải pháp chuyên dụng như Elasticsearch thay vì lạm dụng NoSQL.

Kinh nghiệm thực tế:

Luôn kiểm tra kế hoạch truy vấn (Execution Plan) bằng lệnh .explain('executionStats') trước khi đưa các câu lệnh query có chứa Regex lên môi trường Production.

1. Kiến trúc kết hợp Redis và MongoDB

Trong các hệ thống Enterprise có lượng truy cập lớn, MongoDB đóng vai trò là Primary Persistent Database (lưu trữ lâu dài), trong khi Redis đóng vai trò là Layer Caching tốc độ cao đặt trước MongoDB.

Để tối ưu hóa thời gian tải cho các tệp tĩnh qua CDN, nhà phát triển cần cấu hình chính xác các HTTP Response Header liên quan đến caching và nén dữ liệu tại Origin Server hoặc trực tiếp trên Edge Server của CDN.

Trong quản trị hệ thống CDN, Geo-blocking và Geotargeting là hai cấu hình dựa trên vị trí địa lý của người dùng (được xác định thông qua địa chỉ IP của họ tại Edge Server).

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

Cache Stampede xảy ra khi một tệp dữ liệu cực kỳ hot (ví dụ: một bài báo nổi tiếng hoặc một cấu hình JSON quan trọng) bị hết hạn cache (Expired) trên toàn bộ hệ thống CDN cùng một lúc.

Khái niệm SSL/TLS Termination trên CDN

Thông thường, kết nối bảo mật HTTPS diễn ra giữa Trình duyệt của người dùng (Client) và Edge Server của CDN. Quá trình giải mã mã hóa (TLS Handshake và Decryption) diễn ra tại Edge Server, được gọi là SSL Termination. Sau đó, tùy thuộc vào cấu hình, CDN có thể giao tiếp với Origin Server thông qua HTTP không mã hóa hoặc tiếp tục mã hóa bằng một kết nối HTTPS khác.

Phân biệt vị trí xử lý lỗi

1. Cấu hình tại Origin Server:
   • Khi xảy ra lỗi (ví dụ: 500 Internal Server Error, 404 Not Found), Origin Server sẽ xử lý code, render ra một trang HTML thông báo lỗi và trả về qua mạng Internet thông qua CDN đến người dùng.
2. Cấu hình tại CDN (Edge Custom Error Pages):
   • CDN chặn các mã lỗi HTTP từ Origin Server trả về (như 5xx, 4xx) ngay tại Edge Server gần nhất, và thay thế bằng một trang lỗi tĩnh được lưu trữ sẵn trực tiếp trên CDN (hoặc được fetch một lần và cache lại).

Tại sao xử lý lỗi ở tầng CDN lại tối ưu hơn?

• Giảm tải cho Origin Server (Offloading): Khi hệ thống đang gặp sự cố (ví dụ: sập database gây ra hàng loạt lỗi 500), nếu hàng triệu người dùng tiếp tục truy cập, Origin Server sẽ tiếp tục phải gánh thêm việc render trang lỗi cho từng request. Nếu dùng CDN, các Edge Server sẽ tự động trả về trang lỗi tĩnh mà không làm phiền đến Origin Server nữa, giúp hệ thống có cơ hội phục hồi.
• Trải nghiệm người dùng tốt hơn (User Experience): Trang lỗi được tải từ Edge Server gần nhất nên tốc độ hiển thị cực kỳ nhanh, ngay cả khi hạ tầng backend đang chết hoàn toàn.
• Tiết kiệm băng thông: Trang lỗi tĩnh trên CDN thường có dung lượng rất nhỏ và được nén tối ưu.

Lưu ý thực chiến cho Junior

Khi cấu hình trang lỗi tùy chỉnh trên CDN, cần lưu ý đến thời gian TTL cho cache của trang lỗi (Negative Caching). Không nên đặt TTL quá dài cho các mã lỗi như 404 nếu ứng dụng của bạn thường xuyên tạo ra các trang mới, tránh trường hợp người dùng đã tạo trang nhưng vẫn thấy báo lỗi 404 do CDN đang cache trang lỗi đó.

Sự khác biệt giữa hai mô hình cân bằng tải trong Microservices:

Để loại bỏ điểm hỏng đơn lẻ (Single Point of Failure) tại tầng Load Balancer, chúng ta không bao giờ chạy duy nhất một Load Balancer mà phải thiết kế mô hình High Availability (HA).

Để duy trì phiên làm việc (Session Persistence hoặc Sticky Sessions) qua Load Balancer, chúng ta có các giải pháp chính sau đây:

Health Check là cơ chế định kỳ mà Load Balancer gửi các tín hiệu (HTTP GET, TCP Ping) đến các Backend Server để kiểm tra trạng thái hoạt động.

SSL Termination (hoặc SSL Offloading) là quá trình giải mã (decrypt) lưu lượng HTTPS thành HTTP tại tầng Load Balancer trước khi chuyển tiếp request đến các Backend Server.

Việc sử dụng Database per Service giúp cô lập dữ liệu, đảm bảo rằng lỗi ở một dịch vụ không gây ra hiệu ứng domino (cascading failure) lên toàn bộ hệ thống. Nếu một dịch vụ gặp sự cố về database, các dịch vụ khác vẫn có thể hoạt động bình thường. Ngoài ra, nó cho phép mỗi dịch vụ lựa chọn công nghệ database phù hợp nhất với nhu cầu truy vấn, giúp tối ưu hóa hiệu năng và khả năng mở rộng độc lập.