分布式学习二:CAP定理

前言

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

微服务分布式部署涉及到了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(最终一致性)

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









仙士可博客
请先登录后发表评论
  • 最新评论
  • 总共0条评论
  • 本站由白俊遥博客程序搭建
    © 2017-1-17 php20.cn 版权所有 ICP证:闽ICP备17001387号
  • 本网站由: 提供cdn加速/云存储服务
  • 联系邮箱:1067197739@qq.com