CAP定理是分布式领域的一个基础定理，它指出了一个分布式系统必须在三个方面进行权衡取舍：一致性、可用性、分区容忍性，下面我们就来聊聊关于关于介绍cap协议的书?接下来我们就一起去了解一下吧!
关于介绍cap协议的书
CAP定理是分布式领域的一个基础定理，它指出了一个分布式系统必须在三个方面进行权衡取舍：一致性、可用性、分区容忍性。
下面从一个最简单的例子开始理解CAP理论。
1、单节点服务对于一个单节点服务，因为只有一个节点，不存在分区，所以没有P，只有CA。所以这是一个CA系统。
首先看C，在CAP定义中， C的含义是任何时间、任何节点读取的数据，都是相同的，即保证了一致性。因为只有一个节点，所以C总是满足。
再看A，在CAP的定义中，A的含义是任何时候、只要有可用节点，就可以提供读写服务，而且读写不会失败。因为只有一个节点，所以A也总是满足。
2、master、slave相对于单节点来说，主备场景至少需要两个节点，一个master、一个slave。主备节点之间定期同步数据。那么这种场景下，属于那种类型？
此时有两个以上节点，所以有分区了，就存在分区容忍性的问题。所以，要么是CP、要么是AP。
之一：
如果主从两个节点可读，因为主从同步需要一点时间，所以不能保证在任何一个时刻，从主从节点读取到的数据完全保持一致。所以，既然不能保证一致性，但可用性提高了。因为master不可用时，slave可提供服务。这是一个AP系统。
之二：
如果master不可用时，必须等待某个slave变成master才可用，此时一定有个时间段不能提供服务（slave to master时长），直到新的master产生。此时，就变成了了一个CP系统。
3、多副本因为三副本情况居多，以三副本为例。副本之间的数据同步方法很多。一致性要求比较高的场景，会选择Paxos或Raft算法保证一致性。如果基于一致性算法读写（多数一致），那么在任何一个分区读写的时候，一定是一致的（因为是多数一致）。但是，一旦遇到分区问题，无法达成多数一致，必然会存在读写失败的情况。
所以，这是一个CP系统，无法保证A。
4、多shard或partition的情形在分布式存储或分布式数据库领域里，shard或partition是常用方式，一般是根据某个属性进行hash，然后进行分区。
就CAP定理而言，与shard或partition并没有直接关系。CAP要求的是一个数据单元（简单理解为row，而不是多raw；或者一个transaction）在读写时，能满足一致性、可用性、分区容忍。在NoSQL或NewSQL领域，很少有跨行事务，所以只考虑单行。单行数据在hash之后分配到某个shard或partition中，所以CAP也仅限于这个特定的shard或partition。
例如：对于hbase，一个partition的region server类似于master、slave之二场景。所以hbase是一个CP系统。
5、HBaseHBase既然属于CP，也就是放弃了A（即可用性），为什么？
从HBase写流程说起，HBase row的写操作由一个region server完成，如果从row的角度看，只有一个节点提供写服务，而一个节点在任何时刻都必然是满足一致性的。
那么，为什么是牺牲可用性（A）呢？从CAP理论出发，要保证A，必须是在任何一个节点down的情况下，依然能保证A。然而，如果一个region server down掉，会有一段时间需要其他server接管，在此期间是无法提供服务的。所以，只有一个region server提供服务，此时region server down掉，必然不能提供服务。所以，不满足A的要求。
6、CassandraCassandra读写一致性级别可配置，在大多数情况下，对一致性要求不是非常高的场景（仍然有最终一致性），Cassandra不保证CAP理论所定义一致性。即在不同分区的读取的数据，可能是不一致的。即Cassandra保证分区可读，但读取的数据会有不一致的可能性。
当配置的一致性级别为ALL、QUORUM时（读 写），如果有超过一定数量的分区失败，写入就会失败。如果写入成功，那么在任何一个分区读取到的数据都保持一致。此时，Cassandra就成为CP系统。
7、kuduKudu的一致性级别相当于Cassandra的QUORUM级别。
,
