CAP原理

CAP 定理指出了，在一个跨区域网络连接，共享数据的分布式系统中，一致性(Consistency)，可用性(Availability)和分区容错性(Partition Tolerance) 这三个约束属性最终只能同时满足二个。

目录

一、CAP原理介绍

二、深入认识CAP

三、CAP原理举例分析

1.在保证CP的情况下

2.在保证AP的情况下

3.在保证AC的情况下

四、总结

---

一、CAP原理介绍

做一个简单的原理介绍：

C：Consistency

        一致性：访问所有的节点，得到的数据结果都是一样的。注意：这里的一致性指的是强一致性，也就是数据更新完，访问任意节点，看到的数据完全一致，要和弱一致性、最终一致性区分开来。

A：Availability

        可用性：所有节点都保持高可用性。注意：这里的高可用还包括，不能出现延迟，如节点B由于等待数据同步而阻塞了请求，那么节点B就不满足高可用性。

也就是说，任何没有发生故障的服务必须在有限的时间内返回合理的结果集。

P：Partiton tolerance

分区容错性：这里的分区指的是网络意义上的分区。由于网络是不可靠的，所有节点之间很可能出现无法通讯的情况，在节点不能通信时，要保证系统可以继续正常服务。

        以实际效果而言，分区相当于对通信的时限要求。如果系统不能够在时限内做到数据一致性，就意味着发生了分区的情况，必须就当前操作在C与A之间做出选择。

CAP原理补充/概述：一个数据分布式系统，不可能同时满足CAP这三个条件。所以系统架构师在设计系统时，不需要将精力浪费在如何设计满足三者的完美分布式系统，而是应该做出取舍。由于我们能确定的就是网络的一个不可靠性质，那么大多开源的分布式系统都会实现P，也就是分区容错性，之后在C与A中做出抉择。

对CAP原理上的一些常见的理解误区！

        网上会有蛮多的文章说CAP原理是分布式系统的基石，但是CAP原理其实是对分布式数据存储系统的一个定论。假设一个分布式系统的各个节点都读写同一个mysql实例，那么对于这个分布式系统来说，讨论CAP原理是没有意义的。因为各个节点之间可以不用因为数据复制而进行相互通信，满足分区容错性(P)，可以随时相应请求，满足可用性(A)，同时因为访问的是同一个数据库实例，本身已经保证了数据一致性(C)。

        所以，在讨论CAP原理的时候，更多的是针对那些有数据存储、数据复制场景的分布式存储系统，像NoSql数据库。由于我们大多数人都不会去设计一款新的NoSql数据库来使用，更多的是使用现成的NoSql开源系统进行数据的存储，比如Hbase、MongoDB、Cassandra等。所以大多数时候，其实我们都用不上CAP理论。

        虽然用不上，但是了解一下还是没有坏处的，下面我们稍微深入了解一下CAP。

二、深入认识CAP

在大致了解了CAP的基本概念后，我们再分别对C A P三个属性进行深入的理解。

C：一致性：

这里的一致性从不同角度有着各自的描述方式，在分布式系统的角度：每个节点的数据是相同的；而在客户端的角度：读操作所得到的数据结果永远是最新写入的。其中需要明确的是，对于分布式系统节点来说，是可能存在出现某一时刻数据不一致的情况：如果在某个节点执行原子操作时，对于执行过程中的节点数据跟其他节点就并不完全一致，只有原子操作执行完成后，节点的数据才会保持同步。比如常见的事务操作，只有事务提交后，客户端才能读取到事务写入的数据，失败则回滚为旧数据，不会出现读取事务中间写入的情况。

一致性要求了在分布式环境下的操作就像在单机上完成的一样，当客户端发出写请求，收到请求的节点会及时响应，并将更新的数据同步到另一个节点，保证数据一致性。

客户端向节点 1 发送写操作，将数据X更新为1；

更新操作成功，系统将更新的数据从节点 1 同步到节点 2，将节点 2 的旧数据X也更新为1；

客户端再向节点 2 发送读请求，获取数据X时，就会得到当下X的最新值：1。

注意：一致性强调了数据的强一致，这一点要求对于一些特定的业务系统来说是至关重要的。如电商系统，业务中的库存扣减、金融系统的转账扣款等场景，任何出现一致性的问题，都可能会造成很严重的后果。

A：可用性：

介绍完一致性，我们来聊聊可用性。虽然可用性概念相对简单，但重要程度跟一致性一样。要让系统满足可用性，就是要保证除了所有节点出现故障的情况外，系统都能返回有效的响应，允许响应给客户端的是旧数据，但是不能出现响应失败，超时的情况。

可用性强调的是服务的可用，但不能保证数据的正确性。用一个简单的例子来描述分布式系统的可用性：允许客户端向节点 1 或者节点 2 发起读操作，当其中一个节点故障了，不管节点之间的数据是否保持一致，只要有任意节点服务能收到请求，就响应X的值，这样就说明这两个节点服务是满足了可用性的。

注意：在可用性的描述，还值得一提的是，什么算有效的响应。要返回有效的响应，不能超时，也不能出错，结果不一定是正确的，比如返回的是旧数据，但是客户端收到后是能进行正常业务处理的。

P：分区容错性：讲完 C 和 A，最后讲一下 P。由于分布式系统多个节点往往部署在多个网络环境下进行互相通信，就难免会遭遇一些网络故障，如网络丢包，网络消息延迟，网络中断等情况，会导致节点之间的通信出现问题，数据同步操作无法完成，分区容错性就要求了系统即使在网络分区出现的情况下，任然能继续对客户端提供服务。

因为分布式系统和单机有所不同， 它涉及到了多节点之间的通信，和数据交互，避免不了网络问题，如果没有分区容错性，就意味着系统不允许出现节点之间通信发生任何错误，错误就意味着系统不可用，这在绝大数系统中无法接受的。因此对节点间的分区故障容错是必须要考虑的，也是CAP定理中首先要保证的原因。

三、CAP原理举例分析

        假设有两个节点 data1 和 data2，以及一个变量数据 number = 1；这时有写请求向 data1 提交了更新，将数据number改变为2。

        接着 data1 就需要将更新后的数据同步给 data2 ，让 data2 更新number的最新值。

接下来我们分3个场景去分析。

1.在保证CP的情况下

        为了保证数据数据一致性，data1 需要将数据复制给 data2，那么两个节点之间需要建立通信，可由于网络原因，通讯出现了问题，导致失败了，比较网络是不可靠的。不过系统又保证了分区容错性，这时候 data2 就不一定能够及时的收到 data1 推送来的数据同步信息。当客户端有请求来访问 data2 的number数据时，为了保证数据一致性，data2 只能阻塞，或者返回错误，提示系统发生了错误，然后等待数据真正同步完成后再返回。

        所以，在保证C and P的情况下，是无法同时保证A的。

2.在保证AP的情况下

        为了保证系统的高可用性，data1 和 data2 都需要在有限时间内返回。同样的由于网络的不可靠，在有限时间内，data2 有可能还没有收到 data1 发来的数据同步信息，这时候返回给客户端的可能就是旧数据，和访问 data1 的数据是不一致的，并不满足C。

        所以，在保证A and P的情况下，是无法同时保证C的。

3.在保证AC的情况下

        如果要保证高可用和一致性，只有在网络情况良好且可靠的情况下才能实现。这样 data1 才能立即将更新的消息发送给 data2。但是我们都知道网络是不可靠的，是会存在丢包的请客。所以要满足及时可靠更新，只有将两个节点data1 data2放到一个区内才可以，也就丧失了P这个保证。其实这时候整个系统也不能算是一个分布式系统了。

        理解CAP理论的最简单方式：可以想象两个节点分处在分区两侧。允许至少一个节点更新状态会导致数据的不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点互相通信，才能既保证C又保证A，这又会导致丧失P性质。

四、总结

关于CAP原理，还需要特别注意的一点是，虽然说我们设计系统不能同时具备CAP这三种特性。但是也并不是说，保证了其中2点后，就完全抛弃了另外一点。只是相对的要做一些牺牲。比如在保证CP的情况下，虽然没办法保证高可用性，可这不意味着可用性就为0，我们可以通过合理的设计尽量的提高可用性，让可用性尽可能的接近100%。同理，在AP的情况下，也可以尽量的保证数据的一致性，或者实现弱一致性，即最终一致性。

结合实际的业务场景、和具体需求，基于CAP定理来进行权衡和设计可用且稳定的分布式系统。

这篇好文章是转载于：学新通技术网