Định lý CAP, Mô hình ACID và BASE

Được Eric Brewer đề xuất năm 1998 và chứng minh chính thức năm 2002, Định lý CAP khẳng định rằng một hệ thống dữ liệu phân tán chỉ có thể đảm bảo tối đa hai trong ba thuộc tính tại một thời điểm:

• Consistency (C — Tính nhất quán): Tồn tại một thứ tự toàn cục (linearizability); mọi nút đều nhìn thấy cùng một giá trị dữ liệu mới nhất đồng thời.
• Availability (A — Tính sẵn sàng): Mọi yêu cầu gửi đến nút không bị lỗi đều nhận được phản hồi không có lỗi (non-error response), không bị treo.
• Partition Tolerance (P — Chịu phân mảnh mạng): Hệ thống vẫn hoạt động ngay cả khi đường truyền giữa các nút bị ngắt quãng hoặc chia cắt thành các phân vùng độc lập.

Sự đối lập giữa hai trường phái thiết kế tập trung (CA) và phân tán (AP) được thể hiện rõ nét qua việc chuyển dịch từ ACID sang BASE:

Để định lượng hóa và tinh chỉnh mức độ nhất quán phía máy chủ theo bài báo kinh điển về Amazon Dynamo, hệ thống sử dụng mô hình Quorum với ba tham số nguyên dương:

• N (Replication Factor): Tổng số bản sao dữ liệu được lưu trữ trên các nút vật lý khác nhau.
• W (Write Quorum): Số lượng nút tối thiểu phải xác nhận ghi thành công trước khi báo cho client.
• R (Read Quorum): Số lượng nút tối thiểu phải trả về dữ liệu khi thực hiện truy vấn đọc.

Đoạn mã Python dưới đây minh họa việc đánh giá thuộc tính nhất quán dựa trên bất đẳng thức Quorum:

def evaluate_quorum(N, W, R):
    """
    N: Tổng số bản sao lưu trữ (Replicas)
    W: Số nút tối thiểu xác nhận ghi (Write Quorum)
    R: Số nút tối thiểu truy vấn khi đọc (Read Quorum)
    """
    is_strong_consistency = (W + R) > N
    has_write_conflict_protection = W > (N / 2)
    
    status = {
        "N": N, "W": W, "R": R,
        "is_strong": is_strong_consistency,
        "majority_write": has_write_conflict_protection,
        "type": "Strong Consistency (Quorum overlap)" if is_strong_consistency else "Weak / Eventual Consistency"
    }
    
    # Ví dụ phổ biến:
    # N=3, W=2, R=2 -> W+R=4 > 3 -> Strong Consistency
    # N=3, W=1, R=1 -> W+R=2 <= 3 -> Eventual Consistency, Latency cực thấp
    return status

print(evaluate_quorum(3, 2, 2))
# {'N': 3, 'W': 2, 'R': 2, 'is_strong': True, 'majority_write': True, 'type': 'Strong Consistency'}

Bên cạnh góc nhìn máy chủ, Jonas Bonér nhấn mạnh góc nhìn từ phía máy khách (Client-side Consistency):

• Read-Your-Writes Consistency: Đảm bảo người dùng sau khi cập nhật dữ liệu sẽ luôn thấy bản cập nhật của chính mình trong các lần truy vấn kế tiếp (không bị router điều hướng sang replica chưa kịp đồng bộ).
• Causal Consistency (Nhất quán Nhân quả): Đảm bảo các sự kiện có mối quan hệ nguyên nhân - kết quả được quan sát theo đúng thứ tự (sử dụng Lamport Timestamp hoặc Vector Clocks).

• Nền tảng Thiết kế Hệ thống và Các Đánh đổi Cốt lõi — Bối cảnh lý thuyết tổng thể và Little's Law.
• Các Mô hình và Topo Sao chép Dữ liệu — Cách dữ liệu được sao chép giữa các node để thỏa mãn W và R.
• Phân mảnh RDBMS, DHT và Hệ sinh thái NoSQL — Khám phá kiến trúc Bigtable (CP) và Dynamo (AP).
• Các Chiến lược Bộ nhớ Đệm Phân tán — Đánh đổi nhất quán khi dùng lớp đệm Cache-Aside và Write-Behind.