Định lý CAP và 5 Câu hỏi "Sống còn" cho Kiến trúc Phân tán

Bạn bắt đầu hành trình thiết kế một hệ thống phân tán. Bạn nắm rõ nghiệp vụ và có ý tưởng tổng quan về kiến trúc tương lai. Khi bắt đầu tính toán cách lưu trữ và truyền tải dữ liệu giữa các node, bạn ngồi xuống với phía kinh doanh (business) và đặt những câu hỏi về yêu cầu hệ thống:

— Anh muốn một hệ thống phân tán với nhiều node, đúng không?
— Đúng rồi.

— Hệ thống phản hồi nhanh cỡ nào?
— Tức thì.

— Ok… Dữ liệu phải luôn mới nhất chứ?
— Dĩ nhiên!

— Và mọi thứ vẫn phải chạy tốt ngay cả khi một nửa số server bị sập?
— Chắc chắn rồi!

— Hiểu rồi… Thế dự án này cụ thể là gì?
— Một quán cà phê ở đầu phố... bọn anh có hai cái bàn, Wi-Fi thì chập chờn, nhưng ước mơ thì lớn.

Đoạn hội thoại này ngay lập tức gióng lên những hồi chuông cảnh báo. Dù là tình huống phóng đại, nó phản ánh thực tế rằng phía kinh doanh thường có những kỳ vọng phi kỹ thuật. Là một kiến trúc sư (architect), nhiệm vụ của bạn là giải thích rằng: không phải tất cả các yêu cầu đều có thể tồn tại cùng một lúc.

Đây là lúc Định lý CAP phát huy tác dụng. Hiểu rõ CAP giúp bạn đặt ra 5 câu hỏi cốt lõi để điều chỉnh kỳ vọng và thiết kế một hệ thống thực sự hoạt động.

Định lý CAP nhập môn

Trước danh sách các yêu cầu mâu thuẫn nhau—"phản hồi tức thì", "dữ liệu luôn đúng", và "không bao giờ chết"—định lý CAP giải thích giới hạn cơ bản của các hệ thống phân tán.

Định lý phát biểu rằng bất kỳ hệ thống lưu trữ phân tán nào cũng chỉ có thể đảm bảo hai trong ba tính chất sau:

• Consistency (C - Tính nhất quán): Mọi node đều nhìn thấy cùng một dữ liệu tại cùng một thời điểm. Dữ liệu đọc ra ngay sau khi ghi phải là mới nhất.
• Availability (A - Tính sẵn sàng): Mọi yêu cầu gửi đến hệ thống đều nhận được phản hồi (không lỗi), bất kể dữ liệu có thể chưa phải mới nhất.
• Partition Tolerance (P - Khả năng chịu lỗi phân vùng): Hệ thống vẫn hoạt động ngay cả khi mất kết nối mạng giữa các node.

Trong môi trường phân tán thực tế, Partition Tolerance (P) là bắt buộc vì mạng lưới luôn tiềm ẩn rủi ro. Do đó, khi mạng gặp sự cố (partition), bạn buộc phải chọn giữa:

• Hệ thống CP: Hy sinh tính sẵn sàng. Nếu không thể đảm bảo dữ liệu đồng bộ do mất mạng, hệ thống sẽ từ chối trả lời hoặc báo lỗi.
• Hệ thống AP: Hy sinh tính nhất quán. Hệ thống sẽ trả về dữ liệu "tốt nhất có thể" (có thể đã cũ) để giữ cho dịch vụ không bị gián đoạn.
• Hệ thống CA: Chỉ tồn tại trên lý thuyết hoặc môi trường lý tưởng không có rủi ro mạng (thực chất là hệ thống tập trung - Monolith).

Để đưa ra kiến trúc tối ưu, hãy thảo luận với business dựa trên 5 câu hỏi sau.

Câu hỏi 1 — Bạn có thực sự cần kiến trúc phân tán không?

Kiến trúc phân tán (Distributed Architecture) đang là xu hướng. Nhiều doanh nghiệp muốn nó vì nghe nói nó giúp mở rộng (scale) tốt hơn. Tuy nhiên, cái giá phải trả là sự phức tạp khổng lồ về vận hành và đồng bộ dữ liệu.

Câu hỏi của Architect:

Chúng ta có lý do thực tế nào cho việc phân tán không? Lượng người dùng hoặc vị trí địa lý có thực sự lớn đến mức một hệ thống tập trung không thể xử lý?

Với quán cà phê nhỏ trong ví dụ trên, một kiến trúc Monolith (nguyên khối) truyền thống đặt trên một server, kèm theo cơ chế backup tốt, là lựa chọn rẻ hơn, nhanh hơn và tin cậy hơn.

Tuy nhiên, nếu quán cà phê mở rộng ra hàng chục chi nhánh toàn cầu, lúc này kiến trúc phân tán mới thực sự cần thiết.

Câu hỏi 2 — Dữ liệu nhất quán quan trọng đến mức nào?

Nếu đã chọn phân tán, chúng ta phải định nghĩa độ "tươi" của dữ liệu.

Câu hỏi của Architect:

Việc dữ liệu phải luôn mới nhất (up-to-date) trên tất cả các node quan trọng đến mức nào đối với dòng tiền của doanh nghiệp?

• Rất quan trọng (CP): Số dư tài khoản ngân hàng, tồn kho thời gian thực. Nếu người dùng thấy số dư sai, rủi ro rất lớn.
• Linh hoạt (AP): Bảng tin mạng xã hội, đánh giá sản phẩm, thực đơn quán cà phê. Nếu khách ở Tokyo thấy review mới chậm hơn 5 giây so với khách ở New York, việc kinh doanh không bị ảnh hưởng.

Trong trường hợp này, hệ thống nên hướng tới Eventual Consistency (Tính nhất quán cuối cùng): chấp nhận độ trễ nhỏ để đổi lấy tốc độ và sự ổn định.

Câu hỏi 3 — Mức độ sẵn sàng (Availability) được kỳ vọng ra sao?

High Availability (HA) rất đắt đỏ. Nó đòi hỏi hạ tầng dư thừa (redundancy), sao lưu và cơ chế tự động chuyển đổi dự phòng (failover).

Câu hỏi của Architect:

Hệ thống có cần hoạt động 24/7 không, hay chúng ta chấp nhận thời gian bảo trì (downtime) nhất định?

Nếu quán cà phê đóng cửa vào ban đêm, việc yêu cầu hệ thống menu online phải online 24/7 là lãng phí tài nguyên không cần thiết.

Câu hỏi 4 — Hệ thống nên cư xử thế nào khi mạng gặp sự cố?

Trong hệ thống phân tán, sự cố mạng là điều "sớm muộn gì cũng xảy ra".

Câu hỏi của Architect:

Khi mất kết nối giữa các cụm máy chủ, chúng ta nên ngừng xử lý để tránh sai lệch dữ liệu (CP), hay tiếp tục phục vụ dù dữ liệu có thể cũ (AP)?

Đây là sự đánh đổi cốt lõi của CAP. Với giao dịch thanh toán, bạn chọn dừng (CP). Với việc xem danh sách món ăn, bạn chọn tiếp tục (AP).

Câu hỏi 5 — Có thể chia nhỏ hệ thống theo từng yêu cầu riêng biệt không?

Đây là câu hỏi mang tính chiến lược nhất. Một hệ thống hiếm khi hoàn toàn là CP hay hoàn toàn là AP.

Câu hỏi của Architect:

Chúng ta có thể tách hệ thống thành các phần nhỏ với các yêu cầu về tính nhất quán và sẵn sàng khác nhau không?

Ví dụ với chuỗi cà phê toàn cầu:

• Xử lý đơn hàng (Order): Cần tính nhất quán chặt chẽ để tránh mất đơn hoặc sai tiền. (Thiên hướng CP).
• Menu & Review: Ưu tiên tính sẵn sàng cao, chấp nhận dữ liệu cập nhật chậm một chút. (Thiên hướng AP).
• Điểm tích lũy: Cần nhất quán, nhưng có thể chấp nhận độ trễ xử lý vài giây.

Việc tách Monolith thành các thành phần dựa trên yêu cầu nghiệp vụ giúp tối ưu hóa chi phí và hiệu năng. Bạn không thể cam kết Availability tuyệt đối cho hệ thống thanh toán (vì nó cần Consistency), nhưng bạn có thể cam kết điều đó cho hệ thống hiển thị Menu.

Kết luận

Kiến trúc phần mềm là nghệ thuật quản lý sự đánh đổi (trade-offs) và kỳ vọng của doanh nghiệp. Định lý CAP là công cụ giúp bạn chuyển dịch yêu cầu của khách hàng từ những đòi hỏi "nhị phân" phi thực tế ("Cái gì cũng phải nhất") sang một "thang đo" thực tế hơn.

Nhiệm vụ của bạn là đặt từng tính năng vào đúng vị trí trên thang đo này:

• Đâu là nơi tính nhất quán là sống còn?
• Đâu là nơi có thể hy sinh sự chính xác tức thì để lấy sự ổn định?
• Đâu là nơi sự phức tạp của hệ thống phân tán thực sự mang lại giá trị?

Bằng cách trả lời 5 câu hỏi này, bạn sẽ không chỉ vẽ ra những biểu đồ đẹp mắt, mà còn xây dựng được những hệ thống bền vững và hiệu quả về mặt chi phí.