如何分析CAP principle ，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

创新互联-专业网站定制、快速模板网站建设、高性价比米易网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式米易网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖米易地区。费用合理售后完善，10余年实体公司更值得信赖。

CAP 定理，估计大部分人都听说过，但CAP 定理的在实际中的价值，其实倒是鲜有人提及。

理解定理到底对实际的操作和使用有什么帮助，估计是很多人都要提及的问题。

Consistency , 一致性

Availability    可用性

Partition tolerance  分区的容错性

但我和我的很多朋友之间讨论这个定理的时候，其实有一些不同的意见，其中关于C 就是有不同的理解

 Consistency ，一致性， 这个一致性，有人理解为在同一个时刻需要数据的一致性，有的人理解是，在最终的一个时刻数据是具有一致性。

这里我想举个例子来讲述一下我理解的 C 到底是什么样子的

例如我们有一个汽车预售系统，而预定汽车在预定期是开放预定的，并且在数量上仅仅有50个名额。 那根据C 的定理， 我们的数据提供的数据 A点写，B点读，C点读，由于B 和 C 之间的网络不通，导致的两个客户端，在访问 B 和 C 节点在同一个时刻可能会得到两个截然不同的值，我个人觉得 这就严重的违背了，C ，这个数据的一致性的定理。 我们需要在一个时刻，客户端访问 ABC，得到的数据是一致的。

可用性 A Availability

基本上在这个概念上，有不同的意见的人比较少，个人理解就是在分布式系统中，任意的可以继续工作的节点都必须对客户的请求产生响应。

上图中 A , B 两个节点是故障点，只有C 节点是存活的，这也就造成两个问题，C 要符合 可用性，则必须能继续提供服务，而提供服务或响应。 其中的响应是包含于 A 和 B 节点一致的服务，例如 读 或 写的服务。

P Partition  tolerance 分区容错性

我们试想如果网络出现问题，则 A , B ,C  不能被互访的时候，每个节点自己就需要单独对客户端进行访问，由于网络的问题，会导致 A, B ,C 三节点的数据不在一致，那么我们的系统还是否能继续工作，则是一个分区的容错性需要考虑的问题。

那么下面的问题是，我知道这个定理到底有什么用？

1  首先，一个数据库系统到底是在使用CAP的那种原理，是需要知道的，知道数据库使用的原理，你就会很清晰的明确的了解到你使用的这个数据库对应的业务是什么。

里有一个我个人最近悟出的道理， 如果选择一个数据库系统仅仅是通过感性来选择，而不是根据业务的特性来选择，则很可能会发生一些尴尬的现象。

例如，我们有一个字幕系统，对我们的系统的要求是，只要能提供数据就好，准确度不要求，但需要持续性的提供服务。

那这样的一个系统我们对于 C   A   P  这三者是怎么考虑的

1 C 数据的一致性

2 A 数据的可用性

3 P 数据的分区容错

根据上面的简单（或许还没有准确秒的） 需求，我们可以大致判断这个系统我们的数据库如果根据 C A P 原理我们能提供的系统方式要保证， A ， P 

从提供服务的  A ， P  两个点.

主要原因是，客户在输入字幕后，如果我们从多个节点中读取，会保证数据的提供，并且在网络或其他节点出现故障时，还能继续提供服务，但我们不能保证的就是数据的一致性，如果客户从 A 节点写入数据，但很可能我们在下一秒，或者几十秒都不能再 B 点读出出数据，或者 C 点已经能读出数据，但B 点和C点的数据不同步，这都是可以被这个系统所容忍的。

而符合我们上面系统中所描述的数据库，有哪些，大名鼎鼎的 Cassandra 就是这样的系统，所以妄图在同一个时间点，必须严格的读取同样的数据，这样的想法，你想都不要想在 cassandra 上使用，同时你要理解这个特性，你也就很清楚cassarda 会应用到哪些系统中，而不会不敢不顾的把cassardra放到银行金融中关于付款，收款之类的系统中使用。

而下面如果我们还有相关的需求，例如我们有一个关于合同签署的系统，顾客在我们这里购买汽车，同时需要签署合同并上传 PDF 的电子版作为最终4S 店和 客户，汽车金融公司，三方的具有法律效力的存档。 如果我们使用分布式系统我们需要保证什么？

1 C 一致性， 2 A  可用性  3  分区容错性

根据业务，我们可以很清楚的明白，C 一致性是我们要保证的，我们不能再 A 节点上传PDF 文档后，在B 节点还查不到， 在C 节点查到的文档和 B 节点不一致，从业务的角度来将，这是不能容忍的。同时如果有 B 节点失效，那C 节点，A 节点还能继续提供相关的服务。 

我们损失的是 A ，可用性，如果我们不能保证 C 的前提下，我们会自动的终止服务。 意思就是如果我们不能保证幸存节点之间的信息是 C ，具有一致性的话，则我们就应该停止服务。

在数据库系统中，例如MONGO DB 就是 支持 CP 的系统， 例如我们有 三个节点的复制集的MongoDB 当我们的受损的节点超过节点数据量的大多数的情况下，系统就会终止相关的服务。

支持 CA 系统的目前有  Apache KAFKA,  其实这个系统中关键点在于他的日志系统在哪里，如果存储日志的主节点和 其他节点无法进行网络数据同步，则能提供服务的就只有这个存储日志的主节点，所以这个KAFKA系统就丢弃了 P 这个属性。

所以在理解了CAP 原理后，你就可以很清楚的，明白你选择的系统适合什么业务，而什么业务又应该选择什么样的系统来支持。

在目前的分布式系统蓬勃发展的情形下，例如 MySQL 的 MGR  则应该是 CP原理的产物（如有不同意见请告知），SQL SERVER 的 AWO 也是类似 CP 的产物，而类似ORACLE 这样的数据库产品，到目前为止，还不属于分布式数据库系统的一员。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联行业资讯频道，感谢您对创新互联的支持。

本文标题：如何分析CAPprinciple
转载来于：http://ybzwz.com/article/ijccgj.html