Đánh đổi giữa Tính Nhất Quán và Tính Sẵn Sàng
Có thực sự tồn tại một hệ thống phân tán mà đáp ứng đủ ba yếu tố "Ngon bổ rẻ"? Trong bài viết này, chúng ta sẽ khám phá các khái niệm cơ bản của tính nhất quán, tính sẵn sàng và khả năng chịu phân mảnh trong hệ thống phân tán, cùng với mối quan hệ của chúng với định lý CAP (CAP Theorem). Chúng ta cũng sẽ tìm hiểu cách mà Redis, MongoDB và Amazon RDS Multi-AZ ứng dụng nguyên tắc này.
I. Khái niệm
Tính Nhất Quán (Consistency)
Trong một hệ thống phân tán, tại cùng một thời điểm, dữ liệu mà các client nhìn thấy phải hoàn toàn giống nhau, bất kể là dữ liệu được lấy từ node nào. Để đạt được tính nhất quán, cần phải đồng bộ hóa dữ liệu cho tất cả các node.
Định nghĩa: Tính nhất quán có nghĩa là tất cả các client nhìn thấy cùng một dữ liệu tại cùng một thời điểm, bất kể họ kết nối với node nào. Để đạt được điều này, dữ liệu phải được gửi ngay lập tức đến tất cả các node trong hệ thống trước khi thao tác ghi được coi là thành công.
Ví dụ: Trong một hệ thống ngân hàng, nếu Balance[A] = $100 và A thực hiện chuyển tiền $50:
- Nếu thành công, Balance[A] sẽ được cập nhật thành $50.
- Nếu thất bại, Balance[A] vẫn giữ nguyên là $100.
Khi A kiểm tra trên tất cả các thiết bị, họ sẽ nhận cùng một kết quả như kỳ vọng.
Tính Sẵn Sàng (Availability)
Tính sẵn sàng yêu cầu hệ thống phải đảm bảo mọi request từ client đều được phản hồi, bất kể phản hồi đó có nhất quán hay không.
Định nghĩa: Tính sẵn sàng có nghĩa là bất kỳ client nào gửi yêu cầu dữ liệu đều nhận được phản hồi, ngay cả khi một hoặc nhiều node bị ngắt kết nối.
Ví dụ: Nếu hai người dùng nhấn like một video trên YouTube, số lượt like trên cả hai thiết bị chỉ tăng thêm 1, giúp người dùng biết họ đã like video. Trong tình huống này, tính sẵn sàng được ưu tiên hơn vì độ chính xác số lượt like không quá quan trọng.
Khả Năng Chịu Phân Mảnh (Partition Tolerance)
Hệ thống phải tiếp tục hoạt động ngay cả khi xảy ra sự cố làm mất kết nối giữa các node với nhau.
Định nghĩa: Khả năng chịu phân mảnh có nghĩa là cụm hệ thống phải tiếp tục hoạt động bất chấp bất kỳ sự cố truyền thông nào giữa các node.
Ví dụ: Hệ thống cloud của Amazon có thể hoạt động ngay cả khi có sự cố phân chia giữa các trung tâm dữ liệu ở các khu vực khác nhau.
Định Lý CAP
Định lý CAP, còn được gọi là "Brewer's theorem", là một nguyên lý trong lĩnh vực hệ thống phân tán, được Eric Brewer công bố vào năm 2000. Định lý này nêu rõ rằng một hệ thống phân tán không thể đồng thời đảm bảo cả ba thuộc tính: Tính Nhất Quán (C), Tính Sẵn Sàng (A) và Khả Năng Chịu Phân Mảnh (P). Thông thường, hệ thống phải lựa chọn đánh đổi giữa C (Tính Nhất Quán) và A (Tính Sẵn Sàng) vì P (Khả Năng Chịu Phân Mảnh) rất khó kiểm soát triệt để.
II. Redis và Định Lý CAP
Trong kiến trúc clustered Redis, khi có một thao tác ghi trên Redis master, các Redis replica sẽ được cập nhật dữ liệu tương ứng:
- Redis master thực hiện ghi trên node của mình.
- Nếu thành công, kết quả sẽ được trả về cho client.
- Đồng thời,
Redis mastersẽ gửi yêu cầu ghi sang cácreplica.
Quá trình này diễn ra bất đồng bộ, do đó, nếu Redis master bị mất kết nối với một trong các replica, thao tác ghi sẽ không được đồng bộ hóa với replica đó. Tuy nhiên, Redis master vẫn xác nhận thao tác ghi thành công, dẫn đến việc dữ liệu trả về từ các Redis replica có thể không chính xác. Điều này cho thấy rằng Redis, với cấu hình mặc định, ưu tiên hai tiêu chí AP (Tính Sẵn Sàng và Khả Năng Chịu Phân Mảnh).
III. MongoDB và Định Lý CAP
Chức năng của MongoDB tương tự như Redis trong cách đồng bộ dữ liệu từ primary shard sang các replica. Khi có một thao tác ghi trên primary shard, các bước thực hiện như sau:
- Kiểm tra tính hợp lệ của
operation, từ chối nếu sai cấu trúc. - Thực thi
operationtrênprimary shard. - Chuyển tiếp
operationcho tất cả cácreplicaliên quan. - Chỉ khi toàn bộ
replicaphản hồi thành công,primary shardmới xác nhận request của client là thành công.
Do đó, khác với Redis, MongoDB hướng tới hai tiêu chí CP (Tính Nhất Quán và Khả Năng Chịu Phân Mảnh), đảm bảo rằng client không thể ghi dữ liệu cho đến khi MongoDB xác nhận quá trình ghi thành công đến tất cả các node.
IV. Amazon RDS Multi-AZ và Định Lý CAP
Amazon RDS (Relational Database Service) là dịch vụ của Amazon, cho phép triển khai cơ sở dữ liệu quan hệ trên cloud. Amazon RDS tương thích với các cơ sở dữ liệu quan hệ phổ biến như PostgreSQL, MySQL, MariaDB và SQL Server. Kiến trúc của Amazon RDS chia thành nhiều region, mỗi region có nhiều Availability Zone (AZ). Khách hàng thường chọn triển khai dịch vụ trên nhiều AZ vì các lợi ích mà nó mang lại. Amazon RDS có một dịch vụ mang tên Amazon RDS Multi-AZ với cơ chế Synchronous replication nhằm tăng khả năng chịu lỗi và đảm bảo tính nhất quán.
Cơ Chế Synchronous Replication
Quá trình Synchronous replication của Amazon RDS tương tự với cách mà MongoDB xử lý đồng bộ dữ liệu giữa các node, với các bước thực hiện như sau:
- Primary instance nhận yêu cầu ghi từ client.
- Primary instance ghi dữ liệu vào transaction log.
- Primary instance thực thi lệnh ghi.
- Gửi transaction log sang replica instance.
- Replica instance ghi dữ liệu vào transaction log của mình.
- Replica instance thực hiện lệnh ghi.
- Replica instance gửi xác nhận (ACK) cho primary instance rằng thay đổi đã được thực thi thành công.
- Primary instance trả phản hồi hoàn thành transaction về client.
Nhờ có quá trình này, RDS Multi-AZ có thể tự động chuyển giao sang replica khi phát sinh sự cố trên primary. Tuy nhiên, việc chờ đợi đồng bộ hóa từ các node sẽ làm tăng độ trễ và ảnh hưởng đến throughput, giảm tính sẵn sàng. Lựa chọn này phù hợp cho các hệ thống yêu cầu tính nhất quán cao và không chấp nhận mất mát dữ liệu.
Bài viết này lấy cảm hứng từ buổi Grokking Webinar về sự đánh đổi giữa tính Nhất Quán và Tính Sẵn Sàng trong các cụm cơ sở dữ liệu. Cảm ơn Grokking đã tổ chức những buổi chia sẻ giá trị và chất lượng.
Nếu bạn thấy bài viết hữu ích, hãy nhấn upvote và để lại bình luận nếu bạn có ý kiến hoặc câu hỏi để cùng thảo luận nhé! Bạn cũng có thể tham khảo các bài viết khác của tôi trên Blog cá nhân hoặc kết nối với tôi qua LinkedIn.
source: viblo
