Created
December 2, 2010 16:03
-
-
Save rponte/725566 to your computer and use it in GitHub Desktop.
CAP - Consistency, Availability and Partition-Tolerant
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CAP - Consistency, Availability and Partition-Tolerant | |
The CAP principle states that in distributed computing when it comes | |
to consistency (C), availability (A) and partition (P) | |
resilience/tolerance you can have only two of the three. | |
I was recently introduced to this principle and find it rather | |
insightful. Basically you can't have your cake and eat it too, | |
otherwise (computing) life would be too easy. | |
Eric Brewer, a University of California, Berkeley professor and the | |
co-founder and Chief Scientist of Inktomi, in a 2000 Principles of | |
Distributed Computing (PODC) talk, stated it was impossible for | |
distributed web services to guarantee consistency, availability and | |
partition-tolerance. | |
Consistency. Think database consistency. A read after an update | |
should reflect the update. | |
Availability. Highly available web services mean every requests | |
should succeed and receive a response. | |
Partition-tolerance. This arise out of the desire for | |
fault-tolerance. The service should be able to function when part of | |
network fails, when a partition between data replicas will still allow | |
the service to operate. | |
Take, for example, the Amazon S3 service (Simple Storage Service). | |
Users can upload data to Amazon, much like a simple FTP service, with | |
very high availability and scalability. | |
Amazon's S3 guarantees availability and partition-tolerance but does | |
not guarantee consistency. Data is replicated to many data centers, | |
and requests will continue to succeed even if communication between | |
data centers fail. However, it is possible that after an upload a | |
download on a different node would fail, because the data has not been | |
replicated to that node. The service is not consistent. Amazon | |
describes this as eventually consistent model. | |
On the other hand, take a service with distributed transactions. It | |
will be consistent and available, but if the network partitions the | |
service will not function. | |
Reference: Brewer's Conjecture and the Feasibility of Consistent, | |
Available, Partition-Tolerant Web Services, Seth Gilbert and Nancy | |
Lynch. | |
More infos, http://en.wikipedia.org/wiki/CAP_theorem |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think your example of Not being partition tolerant is a bit incorrect.
A distributed system is always partition tolerant and Consistency or Availability is compromised to some extent according to the need.
In the case of a service with distributed transactions, Consistency is more important and in case of network partition (and when updates are happening), the Availability is compromised.