CAP Theorem: Điều bạn cần biết khi xây dựng Hệ Thống Phân Tán

CAP Theorem là một khái niệm cốt lõi mà mọi developer cần hiểu rõ khi thiết kế hệ thống phân tán. Nó chỉ ra một thực tế quan trọng: không một hệ thống nào có thể đồng thời đạt được cả ba yếu tố – nhất quán (Consistency), sẵn sàng (Availability) và Partition Tolerance.

Tại sao bạn không thể đạt được cả ba yếu tố này cùng lúc? Bài viết này sẽ giúp bạn hiểu rõ về những đánh đổi quan trọng giữa Consistency, Availability và Partition Tolerance, và cách đưa ra lựa chọn phù hợp cho dự án của mình.

1. Định lý CAP là gì?

CAP Theorem được đề xuất bởi Eric Brewer vào năm 2000 và sau đó được chứng minh bởi Seth Gilbert và Nancy Lynch vào năm 2002. Định lý này phát biểu rằng một hệ thống dữ liệu phân tán không thể đồng thời đảm bảo cả ba tính chất sau:

1. Tính nhất quán (Consistency): Mọi thao tác đọc đều nhận được dữ liệu từ thao tác ghi gần nhất hoặc một thông báo lỗi..
2. Tính sẵn sàng (Availability): Mọi yêu cầu đều nhận được phản hồi (không lỗi), mặc dù không đảm bảo rằng phản hồi đó chứa phiên bản mới nhất của dữ liệu.
3. Partition Tolerance: Hệ thống tiếp tục hoạt động ngay cả khi có sự cố về mạng làm cho các node không thể giao tiếp với nhau.

Nghe qua thì có vẻ vô lý, ai chẳng muốn cả ba? Nhưng đó là sự thật phũ phàng mà toán học đã chứng minh. Bạn chỉ có thể đảm bảo tối đa hai trong ba tính chất này đồng thời.

2.  Ba yếu tố C, A và P trong CAP Theorem

2.1 Consistency (Tính nhất quán)

Tính nhất quán đảm bảo rằng mọi node trong hệ thống đều có cùng một trạng thái dữ liệu tại cùng một thời điểm. Khi bạn cập nhật dữ liệu trên một node (ví dụ: node A), tất cả các node khác (B, C...) phải ngay lập tức phản ánh giá trị đã được cập nhật. Nếu không thể đảm bảo điều này, hệ thống sẽ từ chối yêu cầu thay vì trả về dữ liệu cũ.

Đây là lựa chọn của các lĩnh vực quan trọng như ngân hàng, thanh toán, hay đặt vé máy bay, nơi mà bất kỳ sai sót nào cũng có thể dẫn đến hậu quả nghiêm trọng.

2.2 Availability (Tính sẵn sàng)

Tính sẵn sàng đảm bảo rằng hệ thống luôn phản hồi các yêu cầu của người dùng, miễn là node phục vụ yêu cầu đó không bị lỗi. Mọi yêu cầu gửi đến một node hoạt động bình thường đều phải được phản hồi. Không có tình trạng "server đang bận, vui lòng thử lại sau". Nếu phải lựa chọn giữa việc trả về dữ liệu cũ hoặc không trả về gì, hệ thống sẽ ưu tiên trả về dữ liệu cũ.

Đây là lựa chọn của các trang mạng xã hội, blog hay các trang tin tức, nơi mà người dùng chấp nhận việc nhìn thấy nội dung cũ còn hơn không thấy bất kỳ thông tin nào.

2.3 Partition Tolerance

Partition Tolerance đảm bảo rằng hệ thống vẫn tiếp tục hoạt động ngay cả khi xảy ra sự cố mạng khiến các node trong hệ thống không thể kết nối với nhau. Partition Tolerance không phải là một lựa chọn, bạn bắt buộc phải thiết kế hệ thống có khả năng chịu được sự cố này, bởi vì các vấn đề về mạng như mất kết nối hay chập chờn là điều không thể tránh khỏi trong thực tế.

Do vậy, khi Partition xảy ra, bạn phải lựa chọn giữa tính nhất quán (Consistency - C) và tính sẵn sàng (Availability - A):

• Nếu ưu tiên tính nhất quán (C): Hệ thống sẽ từ chối một số request, đảm bảo rằng dữ liệu trên các node phải luôn đồng bộ và không bị sai lệch.
• Nếu ưu tiên tính sẵn sàng (A): Hệ thống sẽ tiếp tục xử lý và phản hồi yêu cầu dù không thể đồng bộ dữ liệu, chấp nhận rằng một số thông tin có thể không chính xác hoặc không phải phiên bản mới nhất.

Ví dụ: Một trang mạng xã hội vẫn tiếp tục hoạt động để xử lý các bài đăng hoặc bình luận, ngay cả khi một số máy chủ không liên lạc được với nhau do sự cố mạng, số lượt like, comment có thể không chính xác do cần đồng bộ tự các node tạm thời không liên lạc được, nhưng không làm ảnh hướng đến trải nghiệm của người dùng.

3. Khi bạn phải lựa chọn giữa CP và AP

3.1 Hệ thống ưu tiên CP

Một hệ thống ưu tiên CP (Consistency và Partition Tolerance) sẽ đặt tính đúng đắn của dữ liệu lên trên tất cả, thậm chí là hơn cả sự sẵn sàng phục vụ của hệ thống. Điều này đồng nghĩa với việc, khi xảy ra Partition, hệ thống sẽ từ chối các yêu cầu nếu không thể đảm bảo tính nhất quán giữa tất cả các node.

Ví dụ thực tế:

• User: Chuyển tiền 1.000.000 VND đến tài khoản B.
• System: "Xin lỗi, không thể xác nhận giao dịch lúc này do sự cố kết nối. Vui lòng thử lại sau."

Hệ thống CP từ chối xử lý giao dịch này bởi vì nó không thể đảm bảo dữ liệu về số dư tài khoản sẽ được cập nhật đồng bộ trên tất cả các node, một số node trong hệ thống đang không phản hồi, và điều gì sẽ xảy ra nếu người dùng chuyển quá số tiền họ có trong tài khoản? Hay người gửi nói rằng giao dịch thành công, nhưng người nhận không nhận được tiền.

Cái giá của CP là tính sẵn sàng (Availability) bị hạn chế. Người dùng có thể gặp thông báo lỗi hoặc không nhận được phản hồi từ hệ thống trong thời gian xảy ra sự cố. Điều này gây khó chịu cho người dùng, nhưng đó là lựa chọn cần thiết để đảm bảo an toàn và tin cậy.

3.2 Hệ thống ưu tiên AP

Một hệ thống ưu tiên AP (Availability và Partition Tolerance) sẽ đặt mục tiêu duy trì tính sẵn sàng lên hàng đầu, ngay cả khi điều này dẫn đến việc dữ liệu tạm thời không nhất quán giữa các node. Trong trường hợp xảy ra Partition, mỗi node trong cluster sẽ tiếp tục xử lý yêu cầu của người dùng, bất kể chúng có thể tạm thời "không đồng ý" về trạng thái dữ liệu.

Ví dụ thực tế:

• User 1 (kết nối với Node A): Thêm bình luận: "Bài viết này thú vị quá!"
• User 2 (kết nối với Node B): Không thấy bình luận đó
• System: "Không vấn đề gì! Họ sẽ thấy bình luận khi mạng được khôi phục và dữ liệu đồng bộ lại."

Hệ thống AP đánh đổi tính nhất quán tạm thời để đảm bảo rằng mỗi yêu cầu từ người dùng được xử lý ngay lập tức. Điều này đặc biệt phù hợp cho các ứng dụng ưu tiên trải nghiệm liền mạch của người dùng – việc hệ thống "không khả dụng" (downtime) sẽ gây khó chịu nhiều hơn so với việc hiển thị dữ liệu chưa được cập nhật hoặc không đồng nhất.

4. Kết luận

CAP Theorem không phải là rào cản khiến chúng ta nản lòng, mà là một công cụ giúp đưa ra những quyết định thiết kế phù hợp. Giống như nhiều khía cạnh khác trong phát triển phần mềm, đây là bài toán về sự đánh đổi.

Đừng cố chống lại Định lý CAP, Thay vào đó, hãy hiểu rõ nó, chấp nhận bản chất của nó, và thiết kế hệ thống của bạn xoay quanh những giới hạn không thể tránh khỏi mà nó đặt ra.