00:00
前面我们说了一下CP定理,并且呢,我们通过RFTT算法的动画演示,我们理解了一下我们RFTT是如何来保证我们CP的,也就说即使我们发生了分区错误,比如我们现在的五个节点,那们这个网络分区,只要发生了这个分区错误,我们最终呢还能保证一致性,怎么叫保证一致性,我们现在两个客户端,他呢,给他提交数据成了,那就是成了,这三个节点都成了,他给他提交的数据与我们这个领导呢,没有大多数的随从能把他的数据同步,所以呢,他一直会给他返回失败,要么就是成了,要么就是败了,那我们这个能不能保证我们的可用性呢?就是我们现在保证了一致性,保证了分区容错,一旦出现错误以后,我们有一致,但是能不能可用,我说这个呢是不能的,因为我们这个要保证一致性的前提,前提呢我们就是要选出一个领导,我们要同步领导的这个数据,那现在假设我们情况是这个样子,我们。
01:00
现在呢有六个节点,那六个节点呢,我们发生了分区错误,我们网络呢,从这中断划分成我们这三个节点,一个区域,这个节点呢一个区域,那这样我们这三个呢,开始来选领导,然后呢,这三个也开始选领导,但是呢,选领导我们的条件就是大多数节点同意,那六个人的大多数不应该是三个,应该是四个人,那这样的话呢,对于这个区来说,无论谁当候选人,他要让别人投票,那永远呢都选不出一个领导,那对于这个区域来说,有可能也是永远选不出一个领导,那在我们这个领导选举期间,我们只要没选出领导,别的客户端想要发请求来保存数据,无论是来干什么事儿,我们这个集群呢,就会直接给他响应,那现在集群呢,是不可用的,所以就会看到效果,就是看起来这几台机器活着启动在这儿,但是呢,就是不能为我们提供功能,那就是不可用状态,因为要保证一致,我们必须得等领导出来。
02:00
所以呢,这就是我们说的CP定理,但在我们这个实际中们这个CP面临的问题是这样子的,在我们这个互联网系统,我们这个大型微服务,我们拆分出了好多微服务,然后呢,我们集群规模非常的大,然后我们这个网络故障肯定是存在的,我们动渣呢,我们这几个机器可能就访问不通了,这个网络呢就中断了,或者这两三个宕机了,那么节点故障,网络故障,这都是常态,但是呢,无论是网络怎么故障,节点怎么故障,我们肯定要保证我们整个集群系统,我们是一个可用状态,不应该出现比如我们这两三个服务出现问题了,或者网络不通了,然后导致我们整个商城呢不可用了,诶我们告诉他拒绝服务了怎么着,所以呢,我们最终都是想要保证我们的服务可用性呢,能达到99.9999%这个效果,所以呢,我们最终还是来选择使用AP,也就是分区容错的情况下,我们保证A而舍弃。
03:00
C,我们所说的这个C就是强一致,我们不要求这个非要立马就要同步一致了,成功就是成功,不成功就是不成功了,我们相当于就要舍弃这个强一支了,那舍弃强一支我们业务肯定得一致啊,得用我们这个订单来说,你们在这儿下单,下单呢在这儿来减库存,库存已经减了,然后呢,在这儿保存订单,订单也存了,然后接下来我们在这儿呢,扣减积分,然后这个积分扣失败了,假设呢,我们订单是掉的,扣减积分,订单回滚了,但已经掉了的扣库存,他没法回滚,这是一个远程方法,但我们不管回不回滚,那我们最终要做的就是我们的扣库存这个方法,你没法回滚,你已经扣了,那我们过上一段时间以后,我看你扣的这个没啥用,我就给你加回来,所以我们分布式系统呢,在我们这个业务里边,我们业务呢,肯定要保证一致的数据,业务前后状态是一致的。加200减点满,但是总数呢是一致的,就跟我们之前说的转账一样,那这个想要怎么保证,那么提出了一个base理论,Base呢其实就是对CP的延伸,就是我们再来保AP的情况下,我们永远无法做到强抑制,就是我们这个业务状态呢,做不了强抑制,做不了强抑志,我们可以怎么办,我们可以让它弱一致,也就是我们说的最终一致,我们发现这个强抑志,弱一志,这两个呢,肯定是对立概念,强抑制那就是我们以前用的这种本地系统,那我们现在呢,就一个数据库,一台机器,我们一个代码在这操作好多数据,那操作完了要么都回滚,要么都失败,这是一个强抑制状态,但我们E在分布式以后呢,我们想要保证强抑制可能很难,那我们可以保证什么呢?保证最终抑制,这就是我们说的base base呢,解释起来就是这个样子,BA,它呢,翻译过来叫基本可用,Basically available,比如说我们这个业务系统呢,基本能用就。
04:58
行了,我们可以让它损失部分的可用性,比如有些东西宕机了,有两三个机器宕机了,我们可以损失一些部分的功能,我们也可以让他损失,包括损失一些响应时间,本来呢,他不宕机,我查他挺快的,他宕机了,我查他不行了,我多查几个其他人,那我们慢一点也行,所以我们最终呢,都是希望一两个节点的不可用,不会导致我们整个系统的不可用。
05:25
所以我们肯定呢,想要让我们整个系统都是可用的,我们可以让它响应时间上有损失,多试几次,也可以让它功能上有损失,比如我们这个购物网站,在高峰期的时候,我们为了保护我们这个系统的稳定性,我们呢可能将部分的消费者流量直接引导到一个,比如直接引导到一个错误页面,就是我们说的这个降级页面,诶当前服务排队人太多了,请稍后重试等等。所以这就是我们说的基本可用,我们要保证业务的基本能用。然后呢,再加上我们的软状态,软状态就指的是我们系统存在中间状态,不像我们的强一致,要么成要么败,我们也可以有一个中间状态,那我正在同步中,比如我们呢,保存了一个数据,他要么有,要么没有,那还有一个正在同步中,哎,我正在把你这个数据给我这个里边做着嘞,所以我们可以有一个中间状态,然后呢,我们希望最终一致,最终一致指的就是我们这个系统里边的这些数据。
06:25
经过一段时间后,最终达到业务状态是一致的,比如我们这个下单方法。我们这个库存扣了订单呢,回滚了库存没办法回滚,像我们之前一样,我们总是有一个东西呢,没办法回滚,那没办法回滚怎么办呢?我们可以占,我现在不要求强抑制了,说他败了,你就必须跟着办,那我可以让系统过一段时间以后,他一检查,诶我们刚才整的这个库存都没人用,那我重新给他再加回来,但是呢,最终导致的就是你如果没有这个订单,我最终呢就不给你扣这个库存,但是我们不是说立马就要不扣的,我们可以让它到达一个最终一致,我们可以用其他各种手段来保证最终一致性,所以这就是我们说的强一支,弱一支,最终一支,所谓的强一致,就是我们要求这个数据更新以后立马就能被看到。
07:20
那我们现在的本地事物,我们现在就是这种强移植状态,然后呢,接下来什么叫弱移植,就是呢,我现在更新完了,可能呢,有一段时间我还看不到,我能容忍部分的时间,部分的时间,或者我们说部分的节点,我这更新成功了,只有这个数据库更成功了,那其他库呢,可能还没有成功,还正在同步中,我们就可以忍受这些正在同步中的过程,如果能忍受,我们就说我们这个事物可以做成一个弱一致性的事物。不是非要这么强的,然后呢,最终我们这个再是弱一致,我们肯定经过一段时间以后,他原来该有什么数据,我们肯定都得同步过来,或者我们这个下单方法,原来扣了的库存最终呢都得加上去,所以这就是我们说的最终一致性,那我们这个分布式事物。
08:11
就是围绕我们想要保证什么样的一致性来做的,那么下节课呢,就来讨论我们分布式事务的几种解决方案。
我来说两句