分布式系统的CAP理论

随着移动互联网的快速发展，互联网的用户数量越来越多，产生的数据规模也越来越大，对应用系统提出了更高的要求，我们的系统必须支持高并发访问和海量数据处理。

分布式系统技术就是用来解决集中式架构的性能瓶颈问题，来适应快速发展的业务规模，一般来说，分布式系统是建立在网络之上的硬件或者软件系统，彼此之间通过消息等方式进行通信和协调。

分布式系统的核心就是可扩展性，通过扩展服务，存储，等提高系统的处理能力。经过多台服务器协同工作，完成单台服务器无法完成工作，尤其是高并发或者大数据量的工作。

除了可扩展性，分布性还要求不出现单点故障与无状态（服务或存储）等特点

• 单点故障（Single Point Failure）是指在系统中某个组件一旦失效，这会让整个系统无法工作，而不出现单点故障，单点不影响整体，就是分布式系统的设计目标之一；
• 无状态，是因为无状态的服务才能满足部分机器宕机不影响全部，可以随时进行扩展的需求。

 

CAP

CAP理论是只在分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

一致性（C）：是指在同一时刻，用户能看到相同的值。即更新操作完成之后，所有节点看到的值是相同的。

可用性(A)：指任何时候，系统读写都是成功的。即使集群一部分节点故障，集群还能响应客户端请求。

分区容忍性（P）：“当部分节点出现消息丢失或者分区故障的时候，分布式系统仍然能够继续运行”，即系统容忍网络出现分区，并且在遇到某节点或网络分区之间网络不可达的情况下，仍然能够对外提供满足一致性和可用性的服务。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。同时，系统经过拆分，P是确定的，所以CAP的应用模型就是CP架构和AP架构。例如分布式系统中，数据无副本备份，那么系统必然满足C，即数据的强一致性，同时系统也满足了P。但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足

CAP应用

不同系统对CAP要求是不同的。例如在微博评论中，用户评论对不一致是不敏感的，可以容忍相对较长时间的不一致，只要做好本地的交互，并不会影响用户体验；而我们在电商购物时，产品价格数据则是要求强一致性的，如果商家更改价格不能实时生效，则会对交易成功率有非常大的影响。

需要注意的是，CAP理论中是忽略网络延迟的，也就是当事务提交时，节点间的数据复制一定是需要花费时间的。即使是同一个机房，从节点A复制到节点B，由于现实中网络不是实时的，所以总会有一定的时间不一致。

CAP架构的取舍

在分布式系统中，为了实现高可用，所以数据会保留多个副本，所以网络分区（P）是既定的事实，所以我们需要的是选择CP还是AP。但是我们需要注意，CAP中的C和A并不是对立的，所以我们需要做的是在满足C或者A的时候，对另一个做尽可能满足。

CP：CP放弃了可用性，满足一致性和分区容错性。典型列子：ZooKeeper。实际应用可用于电商系统，因为产品价格是要求一致，即作出更改所有节点必须能看到。

AP：AP放弃了强一致性，满足了分区容错性和可用性。实际上大部分分布式系统都是采用的这种架构。典型列子：Eureka