CAP Theorem Trong Thực Tế: Bạn Đang Thực Sự Chọn Gì

Định lý trong một câu

Một hệ thống phân tán không thể đồng thời đảm bảo Consistency (mọi đọc trả về bản ghi mới nhất), Availability (mọi request nhận được response), và Partition Tolerance (hệ thống tiếp tục hoạt động khi message bị mất).

Tại sao Partition Tolerance không phải là lựa chọn

Network partition không phải là edge case lý thuyết. Mạng bị drop packet. Data center mất kết nối. Kubernetes pod fail health check. Nếu hệ thống của bạn bao gồm nhiều hơn một process, bạn phải giả định partition sẽ xảy ra.

Điều này có nghĩa bạn không thực sự chọn từ ba tùy chọn. Bạn chọn CP hoặc AP — phải hy sinh gì khi partition xảy ra.

CP: Chọn Consistency

Khi partition xảy ra, hệ thống CP từ chối phục vụ dữ liệu cũ. Nó trả về lỗi hoặc chờ đến khi partition phục hồi và các node có thể đồng thuận về trạng thái hiện tại.

Ví dụ: ZooKeeper, etcd. Đây là công cụ dùng cho distributed coordination (lock, bầu chọn leader, cấu hình) nơi mà đọc dữ liệu cũ sẽ tệ hơn là không đọc gì.

Khi nào chọn CP: configuration store, sổ sách tài chính, đếm hàng tồn kho, bất kỳ domain nào mà hai process hành động dựa trên dữ liệu cũ gây ra vấn đề correctness không thể phục hồi.

AP: Chọn Availability

Khi partition xảy ra, hệ thống AP tiếp tục phản hồi với bất kỳ dữ liệu nào nó có, dù dữ liệu đó có thể cũ. Nó hy sinh consistency để đổi lấy uptime.

Ví dụ: Cassandra, CouchDB, DNS.

Khi nào chọn AP: đọc dữ liệu cho user-facing nơi kết quả hơi cũ vẫn tốt hơn là lỗi 503. Trang catalog sản phẩm, news feed mạng xã hội, analytics dashboard.

Phổ rộng hơn hai tùy chọn

Các hệ thống thực tế không nghiêm ngặt CP hay AP. Chúng cung cấp tunable consistency level cho phép bạn đưa ra lựa chọn theo từng operation.

Consistency level của Cassandra:

• ALL — mọi replica phải phản hồi (hành vi CP, consistency tối đa)
• QUORUM — đa số phải phản hồi (cân bằng giữa consistency và availability)
• ONE — bất kỳ replica nào phản hồi (hành vi AP, availability tối đa)

PACELC: Bức tranh đầy đủ hơn

CAP chỉ xem xét trường hợp partition. PACELC mở rộng: ngay cả khi không có partition, bạn vẫn đánh đổi latency (L) với consistency (C). Hầu hết quyết định production nằm ở PACELC, không phải CAP.

Danh sách kiểm tra thực tế

Trước khi chọn consistency model, hãy trả lời:

1. Điều gì xảy ra nếu user đọc dữ liệu cũ? Nếu câu trả lời là "họ thấy giá cũ" — có thể ổn với AP. Nếu là "họ có thể đặt chỗ đã được đặt" — bạn cần CP.
2. Điều gì xảy ra nếu hệ thống không khả dụng? Nếu "doanh thu ngừng lại" — availability quan trọng hơn. Nếu "job nền xếp hàng và bắt kịp sau" — consistency quan trọng hơn.
3. Bạn có thể bù đắp không? Eventual consistency chấp nhận được nếu bạn có quy trình reconciliation.

Lỗi cần tránh

Coi CAP là thuộc tính của database bạn chọn, không phải cấu hình bạn áp dụng. Cassandra có thể hoạt động như CP ở mức ALL hay AP ở mức ONE. Lựa chọn là của bạn khi query — hãy thực hiện có chủ đích.