分布式架构的CAP原理

分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。

分布式系统的设计目标一般包括:

  1. 性能:分布式系统对外提供服务时的延时和吞吐率是必须要满足用户需要的;
  2. 可用性:这是分布式系统的核心需求,表示分布式系统是否处于整体可服务并且一直可服务的状态;
  3. 容错性:分布式系统发生故障时,系统有对故障进行规避和恢复的能力;
  4. 扩展性:增加一台机器不会改变或极少改变其2系统行为,并能获得近似线性的性能提升;

分布式架构的CAP原理
CAP理论:
一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。

选项 描述
C(Consistence)一致性 数据在多个机器上都能够保证数据的一致
A (Availability) 可用性 系统提供的服务必须一直处于可用的状态,每一次请求都可以在一定响应时间内做出响应,但是不能保证获取数据为最新数据。
P(Netword parttitioning) 分区容错性 分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络发生了故障

那么取舍的策略就共有三种:

CA without P:如果不要求P(不允许分区),则C(强一致性)和A(可用性)是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性,也就是分布式节点受限,没办法部署子节点,这是违背分布式系统设计的初衷的。

CP without A:如果不要求A(可用),相当于每个请求都需要在服务器之间保持强一致,而P(分区)会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务),一旦发生网络故障或者消息丢失等情况,就要牺牲用户的体验,等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少,最典型的就是分布式数据库,如Redis、HBase等。对于这些分布式数据库来说,数据的一致性是最基本的要求,因为如果连这个标准都达不到,那么直接采用关系型数据库就好,没必要再浪费资源来部署分布式数据库。

AP wihtout C:要高可用并允许分区,则需放弃一致性。一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景,可能前几秒你浏览商品的时候页面提示是有库存的,当你选择完商品准备下单的时候,系统提示你下单失败,商品已售完。这其实就是先在 A(可用性)方面保证系统可以正常的服务,然后在数据的一致性方面做了些牺牲,虽然多少会影响一些用户体验,但也不至于造成用户购物流程的严重阻塞。