前言
我们通过微服务形式进行实现整个系统,每个服务都可以有副本,相互之间可以通信,并发能力强
微服务分布式部署涉及到了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（最终一致性）
例如 分布式共识算法 在节点出现错误后,通过选举投票等方法重新决定新的处理节点,在节点恢复后同步数据
