CAP Theorem là gì? Tìm hiểu Consistency, Availability và Partition Tolerance
1. CAP Theorem là gì?
CAP Theorem (định lý CAP) là một nguyên lý quan trọng trong thiết kế hệ thống phân tán, mô tả sự đánh đổi giữa tính nhất quán (Consistency) và tính sẵn sàng (Availability) khi xảy ra phân vùng mạng (Network Partition).
Trong hệ thống phân tán, dữ liệu thường được lưu trữ hoặc sao chép trên nhiều máy chủ (node) để tăng khả năng chịu lỗi, mở rộng và phục vụ nhiều request đồng thời.
Khi các node có thể giao tiếp bình thường, hệ thống có thể phối hợp để cập nhật và đồng bộ dữ liệu. Tuy nhiên, nếu mạng gặp sự cố khiến một số node không thể liên lạc với nhau, hệ thống phải quyết định cách xử lý các request trong khi kết nối chưa được khôi phục.
CAP Theorem giải thích rằng trong tình huống phân vùng mạng thực sự xảy ra, một hệ thống phân tán không thể đồng thời bảo đảm cả hai thuộc tính sau:
- Consistency: Các thao tác đọc và ghi tuân theo một thứ tự nhất quán với các thao tác đã hoàn thành.
- Availability: Mọi request gửi đến node không bị lỗi đều nhận được phản hồi hợp lệ trong thời gian hữu hạn.
Thuộc tính thứ ba, Partition Tolerance, mô tả khả năng hệ thống tiếp tục vận hành theo thiết kế khi mạng bị phân vùng.
Ý tưởng cốt lõi của CAP là: khi không thể bảo đảm việc giao tiếp giữa các node, hệ thống phải đánh đổi giữa việc tiếp tục phản hồi request và việc duy trì tính nhất quán mạnh.
2. Ba thuộc tính của CAP
2.1. Consistency (C) — Tính nhất quán
Trong CAP, Consistency thường được hiểu là tính nhất quán tuyến tính (Linearizability). Các thao tác đọc và ghi phải hoạt động như thể mỗi thao tác được thực hiện nguyên tử tại một thời điểm duy nhất, phù hợp với thứ tự thời gian thực của những thao tác đã hoàn thành.
Ví dụ, một người dùng cập nhật số dư tài khoản từ 1.000.000 đồng thành 800.000 đồng. Sau khi hệ thống xác nhận cập nhật thành công, một lần đọc mới phải phản ánh giá trị mới nếu hệ thống cam kết Linearizability.
Trong hệ thống có nhiều bản sao dữ liệu, điều này đòi hỏi các node phối hợp để tránh trả về dữ liệu cũ trái với bảo đảm nhất quán đã cam kết.
2.2. Availability (A) — Tính sẵn sàng
Availability trong CAP yêu cầu mọi request đến một node không bị lỗi phải nhận được phản hồi hợp lệ trong thời gian hữu hạn.
Phản hồi đó không nhất thiết phải là dữ liệu mới nhất theo thứ tự thời gian thực, nhưng cũng không thể đơn giản từ chối mọi request chỉ vì node không liên lạc được với các node khác.
Ví dụ, khi đường truyền giữa hai trung tâm dữ liệu bị gián đoạn, hệ thống vẫn tiếp tục phản hồi các request tại những node đang hoạt động.
Tuy nhiên, nếu hệ thống không thể xác minh dữ liệu mới nhất, việc tiếp tục phục vụ request có thể dẫn đến việc trả về dữ liệu cũ hoặc chấp nhận các cập nhật xung đột.
2.3. Partition Tolerance (P) — Khả năng chịu phân vùng mạng
Network Partition xảy ra khi mạng bị lỗi khiến các node hoặc nhóm node không thể trao đổi thông tin với nhau, dù bản thân các node vẫn có thể hoạt động.
Ví dụ, một hệ thống có hai node A và B tại hai trung tâm dữ liệu. Khi kết nối giữa hai trung tâm bị đứt, A không thể gửi thông tin cập nhật cho B và ngược lại.
Partition Tolerance là khả năng hệ thống tiếp tục xử lý tình huống phân vùng mạng theo thiết kế, thay vì giả định rằng các node luôn có thể giao tiếp với nhau.
Trong môi trường phân tán thực tế, không thể loại bỏ hoàn toàn nguy cơ phân vùng mạng. Vì vậy, thiết kế hệ thống thường phải tính đến tình huống này.
3. CAP Theorem hoạt động như thế nào?
Giả sử một hệ thống có hai node A và B cùng lưu số dư của một tài khoản.
Ban đầu, cả hai node đều có giá trị 1.000.000 đồng.
Khi mạng giữa hai node bị phân vùng, A và B không thể đồng bộ dữ liệu với nhau. Một request cập nhật số dư được gửi đến A, trong khi một request đọc dữ liệu được gửi đến B.
Lúc này, hệ thống có hai hướng xử lý chính.
3.1. Ưu tiên Consistency
Node A có thể chấp nhận cập nhật chỉ khi đáp ứng đủ điều kiện nhất quán cần thiết. Nếu không thể liên lạc với các node cần thiết để xác minh hoặc phối hợp, hệ thống có thể từ chối hoặc trì hoãn request.
Cách này giúp tránh việc chấp nhận những cập nhật không thể bảo đảm tính nhất quán mạnh.
Đổi lại, một số request sẽ không nhận được kết quả thành công trong thời gian mạng bị phân vùng.
3.2. Ưu tiên Availability
Node A và B tiếp tục phản hồi request độc lập, ngay cả khi không thể trao đổi dữ liệu với nhau.
Cách này giúp duy trì khả năng phục vụ, nhưng các node có thể tạm thời lưu những giá trị khác nhau. Nếu cả hai cùng chấp nhận cập nhật xung đột, hệ thống cần cơ chế giải quyết xung đột khi kết nối được khôi phục.
Đây là sự đánh đổi cốt lõi được CAP Theorem mô tả.
4. CP, AP và CA là gì?
Dựa trên cách xử lý khi xảy ra Network Partition, hệ thống thường được phân loại theo ba cách gọi CP, AP và CA.
4.1. CP — Consistency và Partition Tolerance
Hệ thống CP ưu tiên duy trì tính nhất quán mạnh khi xảy ra phân vùng mạng. Nếu không thể thực hiện một thao tác mà vẫn bảo đảm tính nhất quán, hệ thống có thể từ chối hoặc trì hoãn thao tác đó.
Ví dụ, một hệ thống quản lý số dư không cho phép một node chấp nhận cập nhật nếu node đó không thể xác minh trạng thái cần thiết để tránh xung đột.
Ưu điểm:
- Hạn chế việc chấp nhận các cập nhật xung đột.
- Phù hợp với những nghiệp vụ yêu cầu bảo đảm nhất quán mạnh.
Nhược điểm:
- Một số request có thể không được xử lý trong thời gian phân vùng mạng.
- Khả năng phục vụ có thể giảm ở những node không thể phối hợp với các node cần thiết.
4.2. AP — Availability và Partition Tolerance
Hệ thống AP ưu tiên tiếp tục phản hồi request khi xảy ra phân vùng mạng, chấp nhận khả năng dữ liệu giữa các node tạm thời không đồng nhất.
Sau khi kết nối được khôi phục, hệ thống có thể đồng bộ dữ liệu và giải quyết xung đột theo quy tắc đã thiết kế.
Ưu điểm:
- Duy trì khả năng phục vụ trong nhiều tình huống mạng bị gián đoạn.
- Phù hợp với một số hệ thống cần tiếp tục hoạt động dù dữ liệu giữa các node chưa đồng bộ ngay.
Nhược điểm:
- Một số request có thể nhận dữ liệu cũ.
- Hệ thống cần cơ chế xử lý xung đột và hội tụ dữ liệu phù hợp.
AP không có nghĩa là dữ liệu luôn sai hoặc hệ thống không bao giờ đạt được tính nhất quán. Nó thể hiện sự ưu tiên khả năng phục vụ khi mạng bị phân vùng.
4.3. CA — Consistency và Availability
CA mô tả hệ thống duy trì Consistency và Availability khi không có phân vùng mạng.
Tuy nhiên, trong tình huống phân vùng mạng thực sự xảy ra, một hệ thống phân tán không thể bảo đảm đồng thời cả Consistency theo CAP và Availability theo định nghĩa của CAP.
Vì vậy, CA thường hữu ích như một cách phân loại lý thuyết trong môi trường không có partition, nhưng không phải lựa chọn đầy đủ cho hệ thống cần tiếp tục hoạt động khi mạng bị phân vùng.
Bảng so sánh
| Tiêu chí | CP | AP | CA |
|---|---|---|---|
| Ưu tiên khi có partition | Consistency | Availability | Không thể bảo đảm đồng thời C và A |
| Có thể từ chối request? | Có | Thường cố gắng tiếp tục phản hồi | Tùy tình huống; không bảo đảm khi partition xảy ra |
| Có thể trả về dữ liệu cũ? | Tránh nếu bảo đảm nhất quán mạnh được duy trì | Có thể | Không thể kết luận khi partition xảy ra |
| Xử lý khi mạng bị phân vùng | Chờ hoặc từ chối thao tác không thể bảo đảm | Tiếp tục phản hồi, chấp nhận trạng thái tạm thời khác nhau | Không thể bảo đảm cả hai thuộc tính |
Các nhãn CP và AP mô tả cách hệ thống ưu tiên xử lý khi xảy ra partition. Chúng không có nghĩa là hệ thống luôn đạt mọi thuộc tính trong mọi điều kiện.
5. Ví dụ thực tế về CAP Theorem
5.1. Hệ thống ngân hàng
Giả sử một hệ thống quản lý số dư có nhiều node. Một giao dịch cần trừ tiền từ tài khoản khách hàng.
Nếu mạng bị phân vùng và node nhận request không thể xác minh trạng thái cần thiết, việc vẫn chấp nhận giao dịch có thể dẫn đến các cập nhật xung đột hoặc vượt quá số dư cho phép.
Hệ thống có thể từ chối hoặc trì hoãn giao dịch cho đến khi đáp ứng đủ điều kiện nhất quán.
Đây là ví dụ về việc ưu tiên Consistency khi xảy ra partition.
5.2. Hệ thống phân phối nội dung
Một hệ thống phân phối nội dung có thể lưu bản sao dữ liệu ở nhiều khu vực địa lý.
Nếu kết nối giữa một số khu vực bị gián đoạn, hệ thống có thể tiếp tục cung cấp nội dung từ bản sao tại khu vực đang hoạt động, ngay cả khi nội dung chưa được cập nhật mới nhất.
Đây là một ví dụ về việc ưu tiên Availability trong một số trường hợp, khi việc phản hồi request quan trọng hơn việc mọi bản sao lập tức có cùng dữ liệu.
Hai ví dụ trên chỉ minh họa các lựa chọn thiết kế. Một hệ thống ngân hàng không nhất thiết phải CP ở mọi chức năng, và một hệ thống phân phối nội dung cũng không nhất thiết phải AP ở mọi thao tác.
6. CAP Theorem có nghĩa là hệ thống chỉ được chọn hai trong ba thuộc tính không?
Cách diễn đạt phổ biến “chỉ được chọn hai trong ba” có thể gây hiểu lầm.
CAP không khẳng định rằng mọi hệ thống luôn phải từ bỏ một thuộc tính ngay cả khi mạng hoạt động bình thường. Định lý tập trung vào tình huống phân vùng mạng.
Khi không xảy ra partition, một hệ thống có thể đồng thời cung cấp tính nhất quán mạnh và tính sẵn sàng theo các định nghĩa tương ứng.
Khi partition xảy ra, các node không thể trao đổi thông tin cần thiết để phối hợp. Nếu hệ thống vẫn phải phản hồi mọi request, nó có thể không còn bảo đảm tính nhất quán mạnh. Ngược lại, nếu muốn duy trì tính nhất quán mạnh, hệ thống có thể phải từ chối hoặc trì hoãn một số request.
Do đó, cách hiểu chính xác hơn là:
Khi xảy ra phân vùng mạng, hệ thống phân tán phải đánh đổi giữa Consistency và Availability; Partition Tolerance là điều kiện mà hệ thống cần tính đến.
7. CAP Theorem khác gì với Consistency trong ACID?
Consistency xuất hiện trong cả CAP và ACID, nhưng hai khái niệm không hoàn toàn giống nhau.
Consistency trong ACID nói về việc transaction duy trì các bất biến và quy tắc hợp lệ của dữ liệu. Ví dụ, một giao dịch chuyển tiền phải bảo đảm các quy tắc nghiệp vụ được đáp ứng.
Consistency trong CAP thường đề cập đến tính nhất quán tuyến tính của các thao tác đọc và ghi trong hệ thống phân tán.
Vì vậy, một Database có transaction ACID không đồng nghĩa rằng toàn bộ hệ thống nhiều node hoặc nhiều service tự động đáp ứng mọi bảo đảm của CAP.
Mỗi khái niệm giải quyết một phạm vi vấn đề khác nhau.
8. CAP Theorem liên quan gì đến Backend và Microservices?
Trong hệ thống Backend, một nghiệp vụ có thể liên quan đến nhiều service và nhiều Database. Các service có thể được triển khai ở những máy chủ hoặc khu vực mạng khác nhau, vì vậy việc giao tiếp giữa chúng có thể gặp lỗi.
CAP giúp lập trình viên hiểu rằng thiết kế hệ thống không chỉ xoay quanh việc dữ liệu được lưu đúng trong một Database, mà còn phải xem xét cách hệ thống phản ứng khi các node không thể trao đổi thông tin.
Ví dụ:
- Với thao tác cập nhật số dư, hệ thống có thể cần bảo đảm nhất quán mạnh và từ chối một số request khi không thể xác minh trạng thái cần thiết.
- Với việc hiển thị lượt xem hoặc một số dữ liệu thống kê, hệ thống có thể chấp nhận dữ liệu chưa được cập nhật ngay lập tức để tiếp tục phục vụ người dùng.
- Với hệ thống Microservices, các quyết định về nhất quán và khả năng phục vụ cần được cân nhắc theo từng nghiệp vụ, thay vì áp dụng một lựa chọn duy nhất cho mọi service.
CAP không trực tiếp quyết định kiến trúc nào tốt hơn. Nó giúp làm rõ những bảo đảm hệ thống có thể duy trì và những đánh đổi cần chấp nhận khi xảy ra lỗi mạng.
9. Kết luận
CAP Theorem là một nguyên lý nền tảng trong thiết kế hệ thống phân tán. Nó mô tả sự đánh đổi giữa Consistency và Availability khi xảy ra Network Partition.
Consistency tập trung vào việc bảo đảm thứ tự đọc và ghi nhất quán; Availability tập trung vào việc phản hồi request; còn Partition Tolerance mô tả khả năng vận hành khi các node mất liên lạc do sự cố mạng.
CP và AP là những cách gọi phổ biến để mô tả các lựa chọn ưu tiên trong tình huống partition. CA không thể bảo đảm đồng thời Consistency và Availability khi partition thực sự xảy ra.
Đối với Backend Developer, hiểu CAP giúp lựa chọn những bảo đảm phù hợp với yêu cầu nghiệp vụ và nhận biết rằng trong hệ thống phân tán, khả năng chịu lỗi, tính nhất quán và khả năng phục vụ luôn cần được cân nhắc cùng nhau.
Nguồn tham khảo
Bài viết khác
Redis & Caching là gì?
Redis & Caching là gì? Hướng dẫn sử dụng Redis trong Go 1. Caching là gì? Vì sao cần cache khi đã có database? Caching (bộ nhớ đệm) là kỹ thuật lưu tạm dữ liệu thường được truy cập để có thể lấy lại nhanh chóng khi cần, thay vì phải thực hiện lại toàn […]
Database Migration là gì?
1. Database Migration là gì? Database Migration là quá trình quản lý và áp dụng những thay đổi đối với cấu trúc hoặc dữ liệu trong cơ sở dữ liệu theo từng phiên bản của ứng dụng. Trong quá trình phát triển phần mềm, yêu cầu nghiệp vụ thường xuyên thay đổi. Một bảng có […]
Severity vs Priority(Độ nghiêm trọng vs Mức độ ưu tiên)
1.Severity và Priority là gì? Phân biệt ra sao? Trong bức tranh toàn cảnh của Vòng đời kiểm thử phần mềm (Software Testing Lifecycle – STLC), việc phát hiện ra lỗi (Bug/Defect) mới chỉ đóng góp 50% vào thành công của quy trình đảm bảo chất lượng. 50% còn lại phụ thuộc hoàn toàn vào […]
Bug Lifecycle & Bug Report
1.Bug Lifecycle & Bug Report là gì? Trong quản lý chất lượng phần mềm, Bug Lifecycle (Vòng đời của lỗi) và Bug Report (Báo cáo lỗi) là hai khái niệm cực kỳ quan trọng giúp kiểm thử viên (Tester) và lập trình viên (Developer) trao đổi, theo dõi và sửa lỗi một cách chuyên nghiệp. […]
Bun ORM là gì?
Bun ORM là gì? Hướng dẫn sử dụng Bun ORM với Go và PostgreSQL 1. Bun ORM là gì? Bun là một thư viện ORM dành cho ngôn ngữ Go, được thiết kế theo hướng SQL-first. Thay vì cố gắng che giấu hoàn toàn SQL phía sau các phương thức trừu tượng, Bun cho phép […]
Positive vs Negative Testing(Kiểm thử tích cực và Kiểm thử tiêu cực)
1.Positive vs Negative Testing là gì? Trong ngành công nghệ phần mềm, chất lượng sản phẩm không bao giờ là một khái niệm đơn chiều. Một ứng dụng được lập trình hoàn hảo trên lý thuyết vẫn có thể sụp đổ hoàn toàn ngay trong ngày đầu tiên phát hành nếu nó chỉ được chuẩn […]
Khoá học lập trình game con rắn cho trẻ em 
