Định lý CAP: Hiểu đúng về Consistency, Availability và Partition Tolerance

Trong thiết kế hệ thống phân tán (Distributed Systems), Định lý CAP (hay còn gọi là Brewer’s theorem) là một trong những kiến thức nền tảng quan trọng nhất mà mọi Software Architect hay Backend Engineer đều phải nắm vững.

Định lý này phát biểu rằng: Một hệ thống phân tán chỉ có thể đảm bảo 2 trong 3 thuộc tính sau đây tại cùng một thời điểm:

1. Consistency (Tính nhất quán)
2. Availability (Tính sẵn sàng)
3. Partition Tolerance (Khả năng chịu lỗi phân mảnh)

Hãy cùng đi sâu vào từng khái niệm.

1. Consistency (Tính nhất quán)

Trong CAP, Consistency có nghĩa là tất cả các node trong cluster đều nhìn thấy cùng một dữ liệu tại cùng một thời điểm.

Khi bạn thực hiện một thao tác ghi (write) thành công vào một node, mọi thao tác đọc (read) ngay sau đó từ bất kỳ node nào cũng phải trả về dữ liệu mới nhất đó.

• Ví dụ: Hệ thống ngân hàng. Khi bạn chuyển tiền, số dư phải được cập nhật ngay lập tức trên toàn bộ hệ thống. Bạn không thể vừa chuyển tiền ở máy ATM A, sang máy ATM B lại thấy số dư cũ.

2. Availability (Tính sẵn sàng)

Availability đảm bảo rằng mọi request gửi tới hệ thống (đang hoạt động) đều phải nhận được phản hồi (thành công hoặc thất bại), không có request nào bị timeout, kể cả khi một số node trong hệ thống bị chết.

Tuy nhiên, phản hồi này không đảm bảo chứa dữ liệu mới nhất (hy sinh Consistency).

• Ví dụ: Số lượt like trên Facebook/TikTok. Nếu một server chứa data mới nhất bị chậm, hệ thống có thể trả về số like cũ (cached) để đảm bảo người dùng luôn thấy nội dung, thay vì báo lỗi.

3. Partition Tolerance (Khả năng chịu lỗi phân mảnh)

Partition Tolerance có nghĩa là hệ thống vẫn tiếp tục hoạt động ngay cả khi kết nối mạng giữa các node bị đứt gãy (network partition), khiến các node không thể giao tiếp với nhau.

Trong môi trường mạng thực tế (Internet), việc mất kết nối là điều không thể tránh khỏi. Do đó, P (Partition Tolerance) gần như là bắt buộc đối với các hệ thống phân tán.

Sự đánh đổi: CP vs AP

Vì P là bắt buộc, nên trong thực tế chúng ta thường chỉ cân nhắc đánh đổi giữa Consistency (C) và Availability (A) khi có sự cố mạng xảy ra.

Hệ thống CP (Consistency + Partition Tolerance)

Hệ thống sẽ ưu tiên tính đúng đắn của dữ liệu. Nếu có sự cố phân mảnh mạng, hệ thống có thể từ chối phục vụ (trả về lỗi hoặc timeout) để ngăn chặn việc dữ liệu không đồng nhất.

• Sử dụng khi: Yêu cầu dữ liệu chính xác tuyệt đối (Tài chính, Ngân hàng, Inventory).
• Database tiêu biểu: MongoDB (mặc định), HBase, Redis (cấu hình Sentinel/Cluster strict).

Hệ thống AP (Availability + Partition Tolerance)

Hệ thống ưu tiên tính sẵn sàng. Nếu có sự cố, hệ thống vẫn trả về dữ liệu (có thể là dữ liệu cũ) để giữ trải nghiệm người dùng không bị gián đoạn. Sau khi mạng kết nối lại, dữ liệu sẽ được đồng bộ sau (Eventual Consistency).

• Sử dụng khi: Yêu cầu trải nghiệm mượt mà, chấp nhận sai lệch nhỏ trong thời gian ngắn (Mạng xã hội, Thương mại điện tử - phần hiển thị sản phẩm).
• Database tiêu biểu: Cassandra, DynamoDB, CouchDB.

Kết luận

Không có “viên đạn bạc” (silver bullet) cho mọi bài toán. Việc hiểu rõ CAP Theorem giúp bạn đưa ra quyết định sáng suốt khi lựa chọn công nghệ Database và thiết kế kiến trúc hệ thống phù hợp với yêu cầu nghiệp vụ của doanh nghiệp.

Lời khuyên: Đừng cố gắng chống lại CAP. Hãy xác định rõ Business Requirement cần C hay A, và thiết kế hệ thống xoay quanh sự lựa chọn đó.

---

Tham khảo từ IBM Cloud & High Scalability