Go微服务: 分布式Cap定理和Base理论

发布于:2024-06-11 ⋅ 阅读:(60) ⋅ 点赞:(0)

分布式中的Cap定理

  • CAP理论
    • C: 一致性,是站在分布式的角度,要么读取到数据,要么读取失败,比如数据库主从,同步时的时候加锁,同步完成才能读到同步的数据,同步完成,才返回数据给程序,这样就能解决数据不一致的问题,简单来说,就是保证数据最新
    • A: 可用性,任何客户端请求,都能得到响应式数据,不会出现响应错误,但可能不包含最新的写入数据,简单来说,就是保证数据不出错
    • P: 分区容错性,由于分布式系统都是通过网络通信的,网络是不可靠的,当任意数量的消息丢失或延迟到达的时候,系统仍然提供服务, 不会挂掉,简单说,就是一直运行,不管内部出现任何数据同步问题,强调的是不挂,但是要保证集群内有足够多的可用节点,所以一般要满足这个P条件
  • CAP理论只有两两相交不能同时满足三点,一般而言,分布式系统要满足P这个要求,就是不能挂掉,所以,要么是CP,要么是AP。而CA类型的就是单体应用,而非分布式应用

Base 理论

  • 这里先看一个场景:有两个人分别是a和b, a在A银行存钱,b在B银行存钱
  • 有一种情况是a给b转账10元,b查询时可能不会及时到账,系统还没有执行完,这样就存在一个中间状态,比如提示1个小时候再查询是否到账,这样就可以从业务层面解决问题
  • 还有一种情况a转了,系统执行了,但是遇到问题了,b没有收到,这时候,a仍然要保持原来的余额,那这时候通知a, 重新转一次账,即可。这一种是银行系统故障问题
  • 为了保持一致性,在高并发的场景中是不可接受的,可以主动提示用户,1小时之后再进行查询,这是一个中间状态,或者设置一个转账中的标识
  • 现在我们思考2个问题,在生产环境中是否可以牺牲可用性?也就是系统不能提供服务了; 是否可以牺牲一致性?也就是数据不一致的问题
  • 我们在分布式服务中就需要做一些取舍,根据自身情况的等级来选择
  • 现在举2个例子:单独的mysql是强一致性,分布式的集群是弱一致性,在强一致性的单独的系统中,基于事务可以回滚;分布式,比如A和B银行,两家银行,都是相互独立的,相互不会被控制,所以是弱一致性
  • 我们现在来看下Base理论的三要素
    • 1 ) 基本可用 Basically Available
    • 系统出现了不可预知的故障,但是能用,相比较正常系统而言会有响应时间上的损失和功能上的损失,比如从原来的 200ms响应到 500ms相应,再比如抢购活动中,抢不到提示稍后再试
    • 2 )软状态 Soft State
    • 也就是可以有一段时间不同步,什么是软状态呢?相对于原子性而言,要求多个节点的数据副本都是一致的,这是一种"硬状态"
    • 软状态是指允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同的节点的数据副本存在数据延时
    • 3 )最终一致性,Eventually Consistent, 简称 E, 最终数据一致就可以了,而不是时时保持强一致。上面说软状态,其实不可能一直是软状态,必须有个时间期限。在期限过后,应当保证所有副本保持数据一致性,从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等因素。A到B银行的转账就是最终一致性的体现

网站公告

今日签到

点亮在社区的每一天
去签到