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

本文主要是介绍Go微服务: 分布式Cap定理和Base理论，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

分布式中的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银行的转账就是最终一致性的体现

这篇关于Go微服务: 分布式Cap定理和Base理论的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---