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

Trong kiến trúc Service-Oriented Architecture (SOA), việc giám sát trạng thái của từng dịch vụ là cực kỳ quan trọng để đảm bảo tính sẵn sàng cao. Khi triển khai các Health Check, hệ thống thường sử dụng hai cơ chế chính:

Trong kiến trúc SOA, các dịch vụ thường xuyên gọi qua lại lẫn nhau. Nếu lập trình viên không chú ý đến tầng giao vận mạng, hiệu năng hệ thống sẽ sụt giảm mạnh do các nguyên nhân sau:

Trong hệ thống SOA, các nghiệp vụ như xuất báo cáo lớn, xử lý hình ảnh/video, hoặc đồng bộ dữ liệu hàng loạt thường mất nhiều thời gian (vài chục giây đến vài phút). Nếu xử lý đồng bộ qua HTTP Request, hệ thống sẽ gặp các vấn đề lớn như Gateway Timeout (HTTP 504), treo thread ở phía server và client mất kết nối giữa chừng.

Phân biệt Sharding và Replication

• Replication (Replica Set): Tập trung vào tính sẵn sàng cao (High Availability) và khả năng chịu lỗi (Fault Tolerance). Dữ liệu được sao chép từ Node chính (Primary) sang các Node phụ (Secondary). Nếu Primary gặp sự cố, hệ thống sẽ tự động bầu chọn (Election) một Secondary mới lên làm Primary.
• Sharding: Tập trung vào khả năng mở rộng theo chiều ngang (Horizontal Scaling). Dữ liệu được phân mảnh (Chunk) và lưu trữ trên nhiều Server (Shard) khác nhau để chia sẻ tải trọng ghi và lưu trữ.

Khi nào cần kết hợp cả hai?

Trong môi trường Enterprise, chỉ dùng Replication không giải quyết được bài toán dữ liệu quá lớn vượt quá dung lượng ổ cứng hoặc tải ghi quá cao. Ngược lại, chỉ dùng Sharding mà không có Replication sẽ khiến hệ thống mất dữ liệu nếu một Shard bị hỏng.

Bản chất của Shard Key

Shard Key là trường dữ liệu được MongoDB sử dụng để phân phối dữ liệu giữa các Shard. Nếu chọn Shard Key có độ biến thiên thấp (Low Cardinality), dữ liệu sẽ bị dồn vào một vài Shard cụ thể, gây ra hiện tượng 'Jumbo Chunks' và mất cân bằng tải (Imbalanced Cluster).

Cơ chế Eviction Policy

Khi bộ nhớ (Maxmemory) của Redis bị đầy, Redis cần giải phóng không gian để lưu trữ dữ liệu mới. Các chính sách Eviction (như allkeys-lru, volatile-lru, allkeys-random) sẽ quyết định Key nào bị xóa.

Định lý CAP

Định lý CAP phát biểu rằng một hệ thống phân tán chỉ có thể đảm bảo đồng thời 2 trong 3 yếu tố: Consistency (Tính nhất quán), Availability (Tính sẵn sàng), và Partition Tolerance (Khả năng chịu lỗi phân vùng).

Khi không thể sử dụng giao dịch ACID trên nhiều cơ sở dữ liệu, chúng ta áp dụng mô hình Saga Pattern để quản lý tính nhất quán. Saga là một chuỗi các giao dịch cục bộ (local transactions) được thực hiện tuần tự. Mỗi bước thực hiện thành công sẽ kích hoạt bước tiếp theo thông qua Event-driven architecture. Nếu một bước thất bại, hệ thống sẽ thực hiện các giao dịch bù (compensating transactions) để hoàn tác các thay đổi đã thực hiện trước đó nhằm đưa hệ thống về trạng thái nhất quán. Có hai cách tiếp cận chính: 1. Choreography: Các dịch vụ tự trao đổi sự kiện với nhau thông qua Message Broker. 2. Orchestration: Một dịch vụ trung tâm (Orchestrator) điều phối toàn bộ luồng giao dịch. Đối với Junior, cần hiểu rõ rằng tính nhất quán ở đây là Eventual Consistency (nhất quán cuối cùng) thay vì Strong Consistency.

Load Balancer đóng vai trò là điểm tiếp nhận yêu cầu duy nhất, giúp phân phối lưu lượng truy cập vào nhiều máy chủ phía sau (backend servers), từ đó tăng khả năng mở rộng và tính sẵn sàng cao (High Availability). 1. Layer 4 Load Balancing: Hoạt động ở tầng Transport (TCP/UDP). Nó dựa vào địa chỉ IP và cổng (port) để định tuyến gói tin mà không cần đọc nội dung gói tin. Ưu điểm là tốc độ cực nhanh và tiêu tốn ít tài nguyên. 2. Layer 7 Load Balancing: Hoạt động ở tầng Application (HTTP/HTTPS). Nó có thể kiểm tra nội dung yêu cầu (URL, Header, Cookie) để đưa ra quyết định định tuyến thông minh hơn. Ví dụ, điều hướng các yêu cầu liên quan đến hình ảnh tới một nhóm server riêng biệt. Trong thực tế, Layer 7 thường được sử dụng để tối ưu hóa trải nghiệm người dùng và bảo mật.

Việc lựa chọn phụ thuộc vào mục đích sử dụng và cấu trúc dữ liệu: 1. Block Storage: Chia dữ liệu thành các khối (blocks) có kích thước cố định. Hệ điều hành coi mỗi khối như một ổ cứng riêng biệt. Nó có độ trễ thấp, phù hợp cho cơ sở dữ liệu (Database) hoặc các ứng dụng yêu cầu hiệu năng đọc ghi cao. 2. Object Storage: Lưu trữ dữ liệu dưới dạng các đối tượng (objects) bao gồm dữ liệu gốc, metadata và định danh duy nhất. Nó không phân cấp thư mục truyền thống mà sử dụng flat namespace. Object Storage có khả năng mở rộng vô hạn, chi phí thấp, phù hợp cho lưu trữ dữ liệu tĩnh như ảnh, video, tệp sao lưu (backup). Junior cần nắm vững rằng Object Storage không phù hợp để chạy các ứng dụng yêu cầu thay đổi dữ liệu liên tục (random write) như hệ quản trị cơ sở dữ liệu.

Rate Limiting là kỹ thuật kiểm soát số lượng yêu cầu (requests) mà một người dùng hoặc một dịch vụ có thể gửi đến hệ thống trong một khoảng thời gian nhất định. Mục đích chính bao gồm: 1. Ngăn chặn tấn công DoS/DDoS: Hạn chế kẻ xấu làm quá tải hệ thống bằng cách gửi hàng triệu yêu cầu mỗi giây. 2. Bảo vệ tài nguyên: Đảm bảo các dịch vụ backend không bị cạn kiệt tài nguyên (CPU, RAM, Database connections). 3. Quản lý chi phí: Đối với các API trả phí, Rate Limiting giúp kiểm soát hạn mức sử dụng. Các thuật toán phổ biến bao gồm Token Bucket (cho phép bùng nổ lưu lượng tạm thời) và Fixed Window (đơn giản, dễ cài đặt). Việc triển khai Rate Limiting thường được thực hiện tại API Gateway hoặc Middleware của ứng dụng.

Sự lựa chọn giữa SQL và NoSQL dựa trên yêu cầu về cấu trúc dữ liệu và tính chất của giao dịch: 1. SQL (Relational Database): Dựa trên mô hình bảng, hỗ trợ các giao dịch ACID mạnh mẽ, đảm bảo tính toàn vẹn dữ liệu cực cao. Phù hợp với các hệ thống tài chính, kế toán nơi dữ liệu có cấu trúc chặt chẽ và mối quan hệ phức tạp. 2. NoSQL (Non-relational): Linh hoạt hơn về cấu trúc (Document, Key-Value, Graph, Column-family). NoSQL thường được thiết kế để mở rộng theo chiều ngang (horizontal scaling) dễ dàng hơn so với SQL. Nó phù hợp cho các hệ thống cần xử lý dữ liệu phi cấu trúc, dữ liệu lớn (Big Data) hoặc yêu cầu tốc độ phản hồi cực nhanh như hệ thống Social Media, Real-time Analytics. Junior cần hiểu rằng không có công nghệ nào là hoàn hảo, việc lựa chọn phụ thuộc vào bài toán cụ thể (Trade-off).

Bản chất vấn đề

Các thuật toán băm (Hashing) cũ như MD5 và SHA-1 có tốc độ tính toán rất nhanh và không có cơ chế chống lại việc dò tìm bằng bảng băm tính sẵn (Rainbow Table) hoặc tấn công brute-force. Khi cơ sở dữ liệu bị rò rỉ, kẻ tấn công có thể dễ dàng khôi phục lại mật khẩu gốc trong thời gian ngắn.

Phân tích cốt lõi

1. Mã hóa đối xứng (Symmetric - ví dụ AES):

Vấn đề bảo mật

Việc hardcode các khóa mã hóa, JWT Secret, hoặc Database Password vào trong source code sẽ dẫn đến rủi ro lớn khi mã nguồn bị lộ trên các hệ thống quản lý mã nguồn công khai hoặc bị rò rỉ nội bộ. Kẻ tấn công có thể dễ dàng giải mã toàn bộ dữ liệu hoặc giả mạo phiên đăng nhập.