Định lý PACELC: Đánh đổi Latency và Consistency

Định lý CAP khẳng định rằng khi xảy ra network partition (P), hệ thống phân tán buộc phải chọn giữa Consistency (C) và Availability (A). Tuy nhiên, CAP chỉ nói về trường hợp có partition — một sự kiện tương đối hiếm trong thực tế.

PACELC mở rộng CAP bằng cách đặt câu hỏi quan trọng hơn: khi không có partition (trạng thái hoạt động bình thường), hệ thống phải đánh đổi giữa Latency (L) và Consistency (C). Công thức đầy đủ:

Partition → chọn A hoặc C / Else → chọn L hoặc C

Phần "Else" mới chính là chế độ vận hành thường ngày và có ảnh hưởng lớn hơn đến các quyết định thiết kế hệ thống so với trường hợp partition. Hiểu rõ tradeoff giữa latency và throughput là nền tảng để áp dụng PACELC hiệu quả.

Sơ đồ dưới đây minh hoạ cách PACELC chia quyết định thiết kế thành hai nhánh rõ ràng: khi có partition và khi không có partition.

Phân loại hệ thống theo PACELC

Các cơ sở dữ liệu phân tán hiện đại không bắt buộc bạn chọn một điểm cố định trên phổ Latency–Consistency. Thay vào đó, chúng cung cấp tunable consistency — cho phép điều chỉnh mức độ nhất quán theo từng query.

Cassandra là ví dụ điển hình với các consistency level từ nhanh nhất (ít nhất quán) đến chậm nhất (nhất quán nhất):

# Cassandra consistency levels
ONE      → 1 replica responds  → ~2ms   (eventual)
QUORUM   → ⌊N/2⌋+1 respond  → ~5ms   (strong for N≥3)
ALL      → All N respond      → ~15ms  (strongest, least available)

Mỗi consistency level là một điểm khác nhau trên phổ Latency–Consistency. Với QUORUM, bạn đạt được strong consistency khi cụm có ít nhất 3 replica — đây là lựa chọn phổ biến nhất cho các ứng dụng cần cân bằng giữa tốc độ và tính đúng đắn.

Tìm hiểu thêm về cách các hệ thống RDBMS, Sharding và NoSQL áp dụng các mô hình consistency khác nhau trong thực tế.

Biểu đồ dưới đây so sánh write latency điển hình của các hệ thống thuộc từng nhóm PACELC, cho thấy rõ mối quan hệ giữa mức consistency và thời gian phản hồi.

Hệ thống PA/EL như DynamoDB có latency thấp nhất (~2ms) vì chỉ cần một replica xác nhận. Ngược lại, PC/EC như Google Spanner phải đợi đồng bộ nhiều node qua TrueTime, đẩy latency lên ~15ms — nhưng đổi lại là strong consistency toàn cầu.

Không có lựa chọn nào là "đúng" cho mọi trường hợp. Thực tế, các phần khác nhau trong cùng một hệ thống có thể áp dụng tradeoff khác nhau:

• Hệ thống tài chính (PC/EC): Giao dịch chuyển tiền, thanh toán cần strong consistency — không bao giờ chấp nhận đọc dữ liệu cũ. Chấp nhận latency cao hơn để đảm bảo chính xác tuyệt đối.
• Social media feed (PA/EL): News feed, like count có thể eventual consistent — người dùng không nhận thấy nếu số like chậm vài giây. Ưu tiên tốc độ hiển thị.
• User session (PA/EL + background sync): Session data có thể đọc từ replica gần nhất với latency thấp, đồng bộ ngầm về node chính. Nếu mất một session do partition, người dùng chỉ cần đăng nhập lại.

Nguyên tắc thiết kế: phân loại từng tính năng theo mức độ tradeoff chấp nhận được, sau đó chọn chiến lược replication và consistency level phù hợp. Kết hợp với hiểu biết về latency và throughput để đưa ra quyết định toàn diện.