前言

我们通过微服务形式进行实现整个系统,每个服务都可以有副本,相互之间可以通信,并发能力强

微服务分布式部署涉及到了3个需求:

C（Consistence）实时一致性 

  在分布式系统的每个服务相互之间的数据存储,需要实时一致性,否则无法同时对外提供服务

A（Availability）

可用性 在集群中每个节点读写必须在第一时间响应,不会受到其他服务的影响

P（Network partitioning) 

分区容错性  分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务

CAP定理

一个分布式系统不可能同时满足一致性，可用性和分区容错性这三个基本需求，最多只能同时满足其中的2个。

CP 

CP指的是在分布式部署中,抛弃一定的可用性,保证数据的最终一致性

例如在分布式系统中,

订单系统新增订单+用户系统扣除余额   如果用户系统无法连接,就会导致只新增了订单,没有扣除金额,为了保证数据的一致性,只能抛弃订单系统的可用性,直接将此次请求返回失败

在一些需要保证数据一致性的分布式系统中,将无法保证服务的可用性 (CAP定理)

AP

AP是指在分布式系统中,保证服务的可用性,抛弃一定的数据强一致性

例如在非数据强一致性的场景(废话)

分布式文章系统,用于展示文章数据的,假设需要更新一条文章数据,只需要通知其他节点,就算节点通知失败,节点B也可以返回旧数据进行响应,保证可用性

AC

AC在CAP系统中,严格意义上来说是不存在的,由于丢弃了P(分区),意味着分布式CAP定理中的"分布式" 已经抛弃了

AC表示在一个系统中(非分布式) 严格保证可用性和数据一致性,因为没有了分区,导致非分布式部署,讨论这个没有意义

非严格CAP

在上面我们了解到了分布式CAP定理中CP,AP以及AC的严格约束情况,而事实上

CAP定理只是表明无法严格实现"CAP" 并不代表直接抛弃其中的一个进行构建系统

这句话可能很难理解,其实就是:

在CP中,会抛弃可用性,保证强一致性,但是在某一些场景中,会增加可用性,削弱强一致性,转为"强可用+弱一致性",

例如mysql主从服务器中,通过binlog同步和读写分离模式,保证了读服务器数据通过主服务器进行更新数据提供读服务,但是读服务器不能进行写操作,这就是一个 弱可用+最终一致性 的场景

CP和AP都有一个着重点,可以根据实际业务额外的弱化另一个部分,实现弱CAP

非严格CAP衍生

为了实现弱CAP,着重C或者A,根据业务场景的不同有着不同的方案

例如  BASE理论:  Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）

例如 分布式共识算法  在节点出现错误后,通过选举投票等方法重新决定新的处理节点,在节点恢复后同步数据