Skip to main content

Tìm hiểu định lý CAP / CAP THEOREM

 Nhiều người trong chúng ta hẳn đã nghe về định lý CAP (CAP theorem), một trong các định lý phổ biến hay được dùng trong việc lựa chọn/phân tích các công nghệ phân tán hiện đại, đặc biệt là NoSQL. 

Nhưng định lý này bắt nguồn từ đâu?

Theo định lý CAP, một hệ thống phân tán chỉ có thể chọn được giữa hai trong ba yếu tố (C-Consistency, A-Availability, P-Partial Tolerance), trong đó sự lựa chọn giữa một trong hai yếu tố C-A được xem là một trong những tranh luận cốt lõi.

  • Consistency: tính nhất quán, tất cả các node phải có dữ liệu đồng nhất với nhau.
  • Availability: tính sẵn sàng hoạt động của các node. Hệ thống có thể vẫn hoạt động được khi một số node bị chết hoặc không sẵn sàng.
  • Partition Fault Tolerance: trạng thái hoạt động của hệ thống khi đường kết nối (mạng) giữa các node bị đứt, hay còn gọi là khả năng chịu lỗi của hệ thống. Hệ thống vẫn phải hoạt động bình thường cho dù các kết nối của các node trong hệ thống bị đứt gãy.

Thật ra, những cuộc tranh luận về C-A vốn dĩ đã xuất hiện trước đó giữa ACID và BASE trong đó các nhà thiết kế có phần thiên về ACID, tuy nhiên, với sự xuất hiện của càng nhiều công nghệ dữ liệu lớn, các hệ thống càng ngày càng bự với càng nhiều server cùng tham gia hệ thống thì việc đảm bảo ACID không còn là chuyện đơn giản. Từ đó, định lý CAP được nêu ra như một mô hình suy nghĩ phù hợp hơn với thời đại công nghệ và dữ liệu lớn.

Chúng ta không thể thiết kế một hệ thống bao gồm cả ba tính CAP, bởi vì đảm bảo tính C (consistency) tất cả các cập nhật dữ liệu phải được thực hiện trên các node cùng một thời điểm. Nhưng nếu đường kết nối (mạng) giữa các node không được đảm bảo dẫn đến việc các node sẽ không được update dữ liệu cùng một thời điểm, điều này dẫn tới việc một vài node dữ liệu sẽ bị out-of-date do chưa được cập nhật dữ liệu từ đó vi phạm tính C (consistency). Và để đảm bảo đối phó với điều này ta sẽ ngừng phục vụ nhữg node bị out-of-date đó cho tới khi nó được update dữ liệu đầy đủ, nhưng việc này lại vi phạm tính A (availability) của hệ thống.

Thông thường, người ta thường đánh đổi yếu tố C để lấy hai yếu tố A và P. Khi đó họ sẽ thay thế Consistency thành eventually consistency (tính nhất quán có độ trễ), làm như thế hệ thống sẽ có hiệu năng tốt hơn

Định lý CAP được tác giả Eric Brewer nêu ra trong bài báo vào năm 1999, sau đó được đề cập lần nữa vào năm 2000 trong hội thảo “the Principles of Distributed Computing” trong một bài nói của mình không kèm chứng minh.

Sau đó 2 năm, hai nhà khoa học máy tính là Seth Gilbert và Nancy Lynch đã mô hình hoá và đưa ra công thức chứng minh cho định lý này trong bài báo xuất bản năm 2002 của mình với tiêu đề “Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services” khiến định lý càng ngày càng phổ biến.

Labels:

Comments

Post a Comment

Popular posts from this blog

Apache Spark Discretized Streams (DStreams) with Pyspark

Apache Spark Discretized Streams (DStreams) with Pyspark SPARK STREAMING What is Streaming ? Try to imagine this; in every single second , nearly 9,000 tweets are sent , 1000 photos are uploaded on instagram, over 2,000,000 emails are sent and again nearly 80,000 searches are performed according to Internet Live Stats. So many data is generated without stopping from many sources and sent to another sources simultaneously in small packages. Many applications also generate consistently-updated data like sensors used in robotics, vehicles and many other industrial and electronical devices stream data for monitoring the progress and the performance. That’s why great numbers of generated data in every second have to be processed and analyzed rapidly in real time which means “ Streaming ”. DStreams Spark DStream (Discretized Stream) is the basic concept of Spark Streaming. DStream is a continuous stream of data.The data stream receives input from different kind of sources like Kafka, Kinesis...
Post a Comment
Read more

6 Rules of Thumb for MongoDB Schema Design

“I have lots of experience with SQL and normalized databases, but I’m just a beginner with MongoDB. How do I model a one-to-N relationship?” This is one of the more common questions I get from users attending MongoDB office hours. I don’t have a short answer to this question, because there isn’t just one way, there’s a whole rainbow’s worth of ways. MongoDB has a rich and nuanced vocabulary for expressing what, in SQL, gets flattened into the term “One-to-N.” Let me take you on a tour of your choices in modeling One-to-N relationships. There’s so much to talk about here, In this post, I’ll talk about the three basic ways to model One-to-N relationships. I’ll also cover more sophisticated schema designs, including denormalization and two-way referencing. And I’ll review the entire rainbow of choices, and give you some suggestions for choosing among the thousands (really, thousands) of choices that you may consider when modeling a single One-to-N relationship. Jump the end of the post ...
Post a Comment
Read more

Khác nhau giữa các chế độ triển khai giữa Local, Standalone và YARN trong Spark

Trong Apache Spark, có ba chế độ triển khai chính: Local, Standalone và YARN. Dưới đây là sự khác biệt giữa chúng: Chế độ triển khai Local: Chế độ triển khai Local là chế độ đơn giản nhất và được sử dụng cho môi trường phát triển và kiểm thử. Khi chạy trong chế độ Local, Spark sẽ chạy trên một máy tính duy nhất bằng cách sử dụng tất cả các luồng CPU có sẵn trên máy đó. Đây là chế độ phù hợp cho các tác vụ nhỏ và không yêu cầu phân tán dữ liệu. Chế độ triển khai Standalone: Chế độ triển khai Standalone cho phép bạn triển khai một cụm Spark độc lập bao gồm nhiều máy tính. Trong chế độ này, một máy tính được chọn làm "Spark Master" và các máy tính khác được kết nối với Spark Master như là "Spark Workers". Spark Master quản lý việc phân phối công việc và quản lý tài nguyên giữa các Spark Workers. Chế độ Standalone phù hợp cho triển khai Spark trên các cụm máy tính riêng lẻ mà không có hệ thống quản lý cụm chuyên dụng. Chế độ triển khai YARN: YARN (Yet Another Resource N...
Post a Comment
Read more