分布式理论CAP_cap理论

一、什么是CAP理论

CAP理论，指的是在一个分布式系统中，Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性)，不能同时成立。

CAP理论是分布式架构中提出来的一种设计思想模型，全称是由Consistency、Availability、Partition Tolerance三个词组成，通过单词便可知其意，其实，这三个词分别代表着不同的含义，在做分布式架构设计时，只能在其三中选其二，并不能同时满足三个思想模型。
分布式理论CAP三者的定义如下：

• 一致性(C ) ：保证所有节点上的数据始终同步。
• 可用性(A )：无论响应成功还是失败，每个请求都是有效的，并不会发生网络超时等情况。
• 分区容错性(P ) ：系统内部（某个节点的分区）中丢失消息，系统也应该可以继续提供服务。一致性和可用性是分布式系统的固有属性。

二、CAP分布模型

CAP理论分布模型是基于区域约束来实现的，包含C（一致性）、A（可用性）、P（分区容错性）三者的关系所形成的理论模型。那么CAP理论模型中这三者是怎么联系起来的呢？由于分布式理论CAP特性，只能同时满足三个领域中的两个，所以，我们在思考过程中也知道，可形成三种情况供选择。CAP分布模型图构建和三者之间的关系如下图：

三、CAP核心思想

CAP理论是分布式架构设计中心思想，其核心思想是在分布式架构体系下，基于什么样的场景构建稳定、健壮、安全、可用的软件系统。那么多年来，CAP理论在互联网界广为人知，被称为“帽子理论”。 这是Eric Brewer教授在2000年举办的ACM研讨会上提出的著名猜想：一致性、可用性、分区容错性(partition-tolerrity )。 2003年，MIT的Gilbert和Lynch正式证明这三者确实不可兼得。 而且CAP被认为是分布式领域的重要理论，被很多人认为是分布式系统设计的金律。

四、CAP解决了什么问题

通过对分布式理论CAP认知，我们都应该了解到软件系统在分布式架构场景下会引发哪些问题，而这些问题的背后又是用什么技术手段或方法去解决的呢？那么我们就带着这个问题去寻找答案，切入点如下图：


我这边画了一张便于理解的系统架构链路分析图，其实，在图中已经解答了我上面所提出的问题。那么图中都隐含了什么呢？下面通过 3 个场景去解答，如下：
1、如何保证数据一致性
首先，需要先理解一致性的概念，指的是在主数据和多副本同步过程中实时保持数据是一致的。CAP理论中所描述的一致性是强一致性的，但在分布式系统场景下是很难保证强一性，通过图中的主库和从库之间一旦发生延迟或超时等其它情况，则无法保证数据的强一致性。而为了避免这种问题，后面又提出了不能保证强一致性的同时，可以保证数据的最终一致性，并不要求实时数据一致的情况。其实，在这里有引入了一个理论，那就是Base理论模型，对于这个理论模型下一篇再深入的进行说明。
2、如何保证系统可用性
那么在分布式架构里面为什么要保证系统可用性，提出的一点就是随着业务量的增长，单系统可承受的压力是受限的，为了解决这个问题，引入了分布式架构多副本、集群模式，这样就解决了系统单点问题。通过图中蓝框部分实现了系统集群化和系统架构高可用，避免因为图中红框里面部分系统中断，造成系统不可用状态。在这里面也隐含的表达了Base理论里面的基本可用特征。
3、为什么要选择分区容错性
在解答这个问题之前，我们先要理解分区容错性的概念，也就是什么是分区容错性。分区容错性是在系统通信层面，能够避免系统的某个分区或网络分区出现问题，导致系统中断不可用状态。那么了解了什么是分区容错性以后，我们接着看图中的蓝框里面的三个系统，在分布式架构下，通常一个请求是由多系统协作完成的。若此时B、C系统内部网络通信发生局部异常，则会直接使系统网络通信之间中断并导致不可用，而在有分区容错性的保证下则会对系统网络通信异常分区隔离，并不会影响整个系统的不可用，所以在分布式架构下分区容错性是必选的，那么对于我们的选择的就只有C和A之间做权衡了。

五、CAP应用场景

CAP理论证明限制在原子读写场景中，声明不支持数据库事务等场景。 将分区的容错性总结为关于网络环境的描述，而不是以前的独立条件。

相对于CAP理论应用场景，一般情况下可根据实际业务场景做选择，但我想提的一点就是主要应用于分布式架构当中，为什么这么说呢？因为你的业务足够简单且单应用架构中，像这种场景下是应用不到的。那么CAP一般都适用于哪些场景呢？通过CAP分布模型（实际业务情况下）分为如下三种情况：

• CA：该方案保证的是系统一致性和可用性，但损失了分区容错性，在基于此方案的前提下，若业务系统构 建于分布式架构场景下，则在系统、服务之间的网络通信分区发生中断，某一块分区出现损坏时，会 导致整个业务系统不可用状态，不管你的系统是否保证了高可用。因为在该方案下，只能在系统和网 络层面去保证网络的分区问题。由于采用该方案的业务系统几乎很少，弊端也明显，所以我们在做业 务架构中做出正确的选择，避免出现不可挽回的损失。
• CP：保证了分布式架构中数据的一致性，该方案适用于对于一致性要求苛刻的业务场景下，会选择此方 案。例如 zookeeper 的内部实现机制就是基于分布式一致性的，能够保证数据的存储不丢失，但某一 时刻出现服务中断，则会导致服务不可用状态。那么大家可能会有疑问，集群化不就行了，但是你要考 虑的前提是单集群里面只有一个leader，若leader服务不可用了，选举情况下也会有一段时间不可用 状态，所以像采用这种方案的情况下只能保证数据一致性，并不能保证服务可用性，但可以尽量做到缩 短选举的时间，间接的保证服务可用性。
• AP：保证了服务在分布式架构中可用性，现在大部分业务系统都是基于此方案去实现的，若是你的业务系 统是对可用性要求比较高，则可采用该方案去实现。那么随着业务量的增长，系统可用性的要求也越 来越高，只要保证有一台服务可用，便可处理内外部请求。但是可用性得到了保证，数据一致性也是 尤为重要的，对于数据一致性要求没那么高的情况下，可以间接的保证数据最终一致性，该特性是基于 Base理论模型中提出来的，也是为了解决分布式架构下一致性问题的致命缺陷。
  

六、总结

分布式理论CAP是基于系统之间的不断重现而精进的，CAP并不是普遍的普通原理和指导思想，它只适用于原子读写的NoSQL和系统架构设计场景，而不适用于数据库系统。现在的分布式系统也不是多年前的简单系统。 如今，分布式系统具有可扩展性、自动化等诸多特性，想成为架构师不仅需要理解 CAP 问题，还需要在设计和开发系统时拓展视野。