Định lý CAP: Luật lệ thép của các hệ thống Database phân tán

Khi dự án của bạn phát triển từ 1.000 user lên 10 triệu user, một máy chủ Database duy nhất (như một con PostgreSQL) sẽ không thể gánh nổi. Bạn quyết định nhân bản (Replicate) nó ra thành 3 máy chủ chạy ở 3 quốc gia khác nhau để chạy nhanh hơn và chống sập. Xin chúc mừng, bạn đã chính thức bước vào thế giới của Hệ thống phân tán (Distributed Systems).

Nhưng ngay khi bước chân vào thế giới này, bạn sẽ lập tức va phải một "bức tường vật lý" không thể vượt qua mang tên Định lý CAP.

Định lý này khẳng định một chân lý tàn khốc: Trong một hệ thống dữ liệu phân tán, bạn chỉ có thể chọn tối đa 2 trong 3 đặc tính: C, A, và P. Bạn không bao giờ có thể đạt được cả 3 cùng lúc.

1. Ba trụ cột của định lý CAP

Để hiểu tại sao lại phải đánh đổi, chúng ta cần mổ xẻ 3 chữ cái này:

C - Consistency (Tính nhất quán)

Tính nhất quán yêu cầu: Mọi máy chủ trong cụm (Cluster) đều phải trả về cùng một dữ liệu mới nhất tại cùng một thời điểm.

• Ví dụ: Bạn vừa đổi avatar trên Server A. Ngay mili-giây tiếp theo, bạn bè của bạn kết nối vào Server B (nằm ở nước khác) cũng phải lập tức nhìn thấy avatar mới. Nếu Server B vẫn hiện avatar cũ, hệ thống đó đã mất tính Consistency.

A - Availability (Tính khả dụng)

Tính khả dụng yêu cầu: Hệ thống phải LUÔN LUÔN trả về phản hồi cho mọi yêu cầu của người dùng, không bao giờ được báo lỗi hay "treo" (Timeout).

• Mặc dù dữ liệu trả về có thể không phải là mới nhất (bị cũ), nhưng máy chủ tuyệt đối không được từ chối phục vụ.

P - Partition Tolerance (Khả năng chịu lỗi phân vùng)

Phân vùng (Partition) xảy ra khi đường truyền mạng bị đứt giữa các máy chủ. Ví dụ: Cáp quang biển bị cá mập cắn, Server A và Server B không thể "nói chuyện" và đồng bộ dữ liệu với nhau được nữa.

• Tính Partition Tolerance yêu cầu: Dù mạng nội bộ bị đứt, cả hệ thống vẫn phải tiếp tục hoạt động và phục vụ người dùng, không được sập dây chuyền.

2. Vì sao phải đánh đổi? (Bài toán cái cáp quang bị đứt)

Tại sao không thể có cả 3? Hãy quay lại kịch bản cáp quang bị đứt (Hiện tượng P xảy ra - Server A không thể gọi cho Server B).

Ngay lúc này, một khách hàng tên Bob gửi lệnh "Đổi Avatar" lên Server A. Server A cập nhật thành công.

Một phần ngàn giây sau, khách hàng Alice kết nối vào Server B và hỏi: "Avatar của Bob là gì?".

Bây giờ, hệ thống của bạn sẽ đứng trước một lựa chọn sinh tử. Vì P (đứt mạng) là yếu tố vật lý không thể tránh khỏi, bạn chỉ có thể chọn 1 trong 2 con đường sau:

Con đường 1: Chọn CP (Consistency + Partition Tolerance) - Hy sinh Availability

Để đảm bảo Alice chắc chắn nhận được Avatar mới (Tính Consistency), Server B bắt buộc phải đợi mạng khôi phục để hỏi Server A xem avatar mới là gì.

Nhưng mạng đang đứt! Do đó, Server B đành phải báo lỗi (Error) hoặc Timeout không phục vụ Alice nữa.

Hệ thống bảo vệ được sự Nhất quán, nhưng đã hy sinh Tính Khả dụng (A).

Con đường 2: Chọn AP (Availability + Partition Tolerance) - Hy sinh Consistency

Server B quyết định: "Khách hàng là thượng đế, thà trả về dữ liệu cũ còn hơn là báo lỗi". Nó lập tức trả về cho Alice bức ảnh Avatar cũ rích của Bob.

Hệ thống đảm bảo 100% Khả dụng (Không ai bị báo lỗi), nhưng đã hy sinh Tính Nhất quán (C).

(Lưu ý: Không có hệ thống CA ngoài đời thực. Vì trên môi trường Internet, mạng chắc chắn sẽ có lúc bị đứt/chậm trễ. Nên bạn bắt buộc phải có P).

3. Hệ thống của bạn thuộc nhóm nào?

Hiểu định lý CAP giúp bạn chọn đúng Database cho đúng nghiệp vụ của công ty:

Nhóm CP (Ưu tiên sự chính xác tuyệt đối)

• Đại diện: MongoDB (Cấu hình mặc định), Redis, HBase, hoặc các hệ thống RDBMS truyền thống (MySQL, PostgreSQL) chạy mô hình Primary-Secondary chặt chẽ.

• Đặc điểm: Sẵn sàng báo lỗi hoặc sập tạm thời (Downtime) chứ tuyệt đối không bao giờ để xảy ra tình trạng "tiền bị trừ mà tài khoản người kia chưa nhận được".

• Use case: App ngân hàng, hệ thống thanh toán, ví điện tử. Lỗi mạng thì hiện popup "Hệ thống đang bận", thà từ chối khách còn hơn là làm sai lệch số dư.

Nhóm AP (Ưu tiên trải nghiệm mượt mà)

• Đại diện: Cassandra, DynamoDB, CouchDB.

• Đặc điểm: Áp dụng cơ chế Eventual Consistency (Nhất quán sau cùng). Tức là hiện tại dữ liệu có thể lệch nhau giữa các server, nhưng "cuối cùng" khi mạng ổn định, chúng sẽ tự đồng bộ lại.

• Use case: Nút Like Facebook, view Youtube, giỏ hàng Shopee. Nếu mạng chập chờn, bạn Like một bài viết, Server A ghi nhận số Like là 1.000. Bạn của bạn nối vào Server B vẫn thấy 999 Like. Chẳng chết ai cả! Vài giây sau Server tự đồng bộ là xong. Miễn sao app luôn mượt, không bao giờ bị đơ là được.

4. Lời kết

Định lý CAP khẳng định rằng thiết kế hệ thống là nghệ thuật của sự Đánh đổi (Trade-off). Không có một công nghệ Database nào là "tốt nhất" hay "xịn nhất".

Chỉ có những kỹ sư tồi cố gắng tìm kiếm một Database hoàn hảo, và những Kiến trúc sư hệ thống (System Architect) giỏi biết cách chia nhỏ ứng dụng của mình ra: Dùng CP Database cho module Thanh toán, và dùng AP Database cho module Hiển thị bài viết!