1. CAP Theorem là gì?
CAP Theorem là một định lý nền tảng trong Distributed Systems, giải thích giới hạn của việc đồng thời đảm bảo ba thuộc tính: Consistency (C), Availability (A) và Partition Tolerance (P) trong một hệ thống dữ liệu phân tán.
Định lý bắt nguồn từ nhận định của Eric Brewer năm 2000 và được Seth Gilbert cùng Nancy Lynch chứng minh chính thức năm 2002. CAP giúp developer và system architect hiểu điều gì xảy ra khi các node lưu trữ dữ liệu không thể liên lạc với nhau do lỗi mạng.
Trong một distributed database, dữ liệu thường được sao chép trên nhiều node để tăng khả năng chịu lỗi, cải thiện hiệu năng đọc hoặc hỗ trợ hoạt động ở nhiều khu vực địa lý. Tuy nhiên, việc sao chép tạo ra một vấn đề: khi các node mất kết nối, mỗi node có thể không biết những thay đổi mới nhất ở node khác.
2. Ba thành phần của CAP Theorem
Consistency (C) – Tính nhất quán
Trong CAP, Consistency có nghĩa cụ thể là mọi thao tác đọc phải nhận được giá trị của lần ghi mới nhất đã hoàn tất, hoặc nhận lỗi nếu hệ thống không thể bảo đảm điều đó.
Bảo đảm này gần với khái niệm linearizability: dù dữ liệu được lưu trên nhiều node, hành vi quan sát được phải tương đương với một bản dữ liệu duy nhất, trong đó mỗi thao tác có thể được xem như có hiệu lực tại một thời điểm hợp lệ giữa lúc bắt đầu và lúc kết thúc thao tác.
Ví dụ, tài khoản có số dư 1.000.000 đồng. Một giao dịch trừ 200.000 đồng hoàn tất thành công và hệ thống xác nhận giao dịch đó. Sau đó, một yêu cầu đọc mới không được trả về số dư 1.000.000 đồng như thể giao dịch chưa xảy ra.
Availability (A) – Khả năng phục vụ yêu cầu
Trong CAP, Availability có nghĩa là mọi yêu cầu được gửi đến một node không bị lỗi phải nhận được phản hồi thành công, không phải lỗi hoặc timeout theo mô hình của định lý.
Điều này không có nghĩa hệ thống chỉ cần có uptime cao. Một dịch vụ hoạt động 99,99% thời gian vẫn có thể không thỏa mãn bảo đảm Availability của CAP nếu trong một network partition, một node đang hoạt động từ chối các yêu cầu mà nó nhận được.
Partition Tolerance (P) – Khả năng chịu phân vùng mạng
Network partition xảy ra khi các node không thể trao đổi thông tin với nhau do lỗi kết nối, mất gói tin hoặc thông điệp bị trì hoãn quá lâu.
Ví dụ, một hệ thống có hai nhóm node:
- Nhóm A ở khu vực địa lý thứ nhất.
- Nhóm B ở khu vực địa lý thứ hai.
Nếu kết nối giữa hai nhóm bị gián đoạn, mỗi nhóm vẫn có thể hoạt động cục bộ nhưng không thể đồng bộ dữ liệu với nhóm còn lại.
Partition Tolerance có nghĩa hệ thống được thiết kế để đối mặt với tình huống thông điệp giữa các node bị mất hoặc trì hoãn tùy ý, thay vì giả định rằng mạng luôn hoạt động hoàn hảo.
3. CP, AP và CA khác nhau như thế nào?
CP – Consistency và Partition Tolerance
Một hệ thống thiên về CP ưu tiên giữ tính nhất quán khi network partition xảy ra. Nếu một node không thể xác minh dữ liệu mới nhất hoặc không thể tham gia cơ chế đồng thuận cần thiết, nó có thể từ chối một số yêu cầu.
Ưu điểm:
- Tránh trả về dữ liệu cũ trong những thao tác cần consistency mạnh.
- Phù hợp với dữ liệu mà một kết quả sai có thể gây hậu quả nghiêm trọng.
- Có thể hỗ trợ những bất biến như chỉ có một chủ sở hữu hợp lệ của một distributed lock.
Nhược điểm:
- Một số request có thể bị từ chối trong thời gian partition.
- Một phần hệ thống có thể mất khả năng đọc hoặc ghi cho đến khi phục hồi kết nối.
- Các thao tác cần đồng thuận giữa nhiều node có thể phải chờ hoặc thất bại nếu không đủ quorum.
AP – Availability và Partition Tolerance
Một hệ thống thiên về AP ưu tiên tiếp tục phục vụ yêu cầu ở các node có thể truy cập, kể cả khi các node không thể liên lạc với nhau. Trong ví dụ trước, B có thể tiếp tục trả về x = 0 dù A đã ghi x = 1. Hệ thống chấp nhận rằng các replica có thể tạm thời không đồng nhất.
Ưu điểm:
- Có thể tiếp tục phục vụ nhiều yêu cầu khi một phần mạng bị gián đoạn.
- Hữu ích cho dữ liệu có thể chấp nhận độ trễ đồng bộ.
- Phù hợp với một số hệ thống cần tiếp tục ghi nhận hoạt động tại nhiều khu vực.
Nhược điểm:
- Client có thể đọc dữ liệu cũ.
- Các replica có thể nhận những cập nhật xung đột.
- Hệ thống phải có chiến lược giải quyết xung đột, đồng bộ lại và bảo vệ bất biến nghiệp vụ.
CA – Consistency và Availability
CA thường được mô tả là hệ thống vừa nhất quán vừa sẵn sàng, nhưng không chịu được network partition. Cách diễn đạt này chỉ có ý nghĩa khi giả định không xảy ra partition, hoặc trong một hệ thống đơn node không có liên kết mạng giữa các replica. Với hệ thống phân tán nhiều node, partition là khả năng phải tính đến. Khi partition xảy ra, hệ thống không thể bảo đảm đồng thời C và A cho mọi request bị ảnh hưởng.
Vì vậy, CA không phải một lựa chọn có thể đạt được trong mọi điều kiện của một hệ thống phân tán thực sự. Một database đơn node có thể cung cấp tính nhất quán và phục vụ request bình thường, nhưng đó không phải lời giải cho vấn đề CAP giữa các replica.
4. CAP và Eventual Consistency
Eventual Consistency là mô hình trong đó các bản sao dữ liệu có thể khác nhau trong một khoảng thời gian, nhưng nếu không còn cập nhật mới và quá trình đồng bộ hoàn tất, chúng sẽ hội tụ theo quy tắc của hệ thống.
Ví dụ:
Ban đầu:
Node A: status = PENDING
Node B: status = PENDING
Node A cập nhật:
Node A: status = CONFIRMED
Node B: status = PENDING
Sau khi đồng bộ:
Node A: status = CONFIRMED
Node B: status = CONFIRMEDTrong khoảng thời gian giữa lần cập nhật và đồng bộ, một client đọc từ B có thể nhìn thấy PENDING dù A đã chuyển sang CONFIRMED.
5. Tổng kết
CAP Theorem giải thích giới hạn của một hệ thống dữ liệu phân tán khi xảy ra network partition. Ba thuộc tính gồm:
- Consistency: đọc được giá trị mới nhất theo bảo đảm mạnh, hoặc nhận lỗi nếu không thể bảo đảm.
- Availability: các request đến node không bị lỗi nhận được phản hồi thành công theo mô hình của định lý.
- Partition Tolerance: hệ thống được thiết kế để đối mặt với việc các node không thể trao đổi thông điệp qua mạng.
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 
