00:00
好,同学们。那么对于我们这个K的删除,我们就给大家介绍到这儿撸啊脚本以前也讲过很多遍,在这带着大家再快快的复习一下过,那么目前我们呢,已经把我们的程序修改到了8.2版。那么,请大家再思考,在8.2版的基础上,我们的程序还会有什么问题?OK,那么很简单,加锁,加了业务逻辑,写了finally,各种也就验证和判断都填充了。那么还有哪些问题呢?来,同学们。结合我们之前的这个架构啊。可以这么讲。对于我们代码层面的,写到这儿,一般的啊,中小型公司你用一下,勉强用一下,只要不是特别的高并发的话,你还是能扛得住点事儿了,真出了一点小异产的话呢,那么到时候数据上修一下也能应付了小厂哈,那么下面的问题是有一个业务上的一个要命的东东。
01:00
我们这儿是十秒钟。也就是说,现在。假设我们要解决的问题就是什么概念呢?确保lock过期时间要大于业务执行时间的问题,也就是我们前期经典的一个问题,就是分布式锁如何实现。缓存续期,缓存加时间加个中。缓存续命好什么意思呢?现在各位亲,什么都好啊。你这设的是十秒钟,你怎么知道这个业务逻辑?十秒钟,100%一定能够执行完。好,你说没关系,你直线不完,我给你加大。20秒好不好意思,由于现在我们这是写的简单,实际上生产各种接口的调,各种服务的调,服务里面调服务,服务里面又调服务,调第三方服务,网络延时,网络抖动,总会出现了超时的情况,那比如说我加到20秒,但不好意思,这次的话可能别的系统断了,我一执行的话,需要28秒钟才执行完。
02:07
总有不够的时候。那么。100秒,那么假设它又超过100秒呢?那么所以说这种情况下而言的话呢,你很难办,很难受,那么这个我们总是希望就说自己加锁成功,自己执行完自己的业务逻辑,然后自己删除自己的锁,而且red这个锁最好还没有过期,说白了就是用完稷山像微信小程序一样的,你不用去装安这APP,但是我并不知道你到底这个业务逻辑需要执行多久,所以说我们现在需要一种机制叫。缓存续命的机制啊。我希望我一成功以后,加锁成功以后,后台马上启动一个后台线程,这样一个线程会去慢慢的扫描我这个快要到期的key,比如说啊,一定实现。假设十秒钟过了以后,我就看看,哎,你这个业务有没有完成,完成了我安安静静的没完成,我就发现哟,我怀疑你现在会出现。
03:05
过期时间和业务时间不够用的情况,那么这样的话我会给你续个时间,比方说再给你延长,要到了的时候我就再给你延长20秒钟,要到的时候再给延长20秒秒钟,这个时候我们每次都来隔一定时间来检查,直到你完成为止,确保你的业务逻辑时间不会超过我的过期时间,这样得到一种保障和程序的健壮性。那么类似于这样的功能,有点类似于我们的原来go游戏里面学过的什么future task。你的主业务流程往下走,但是我后台横过来起了一个线程,默默的保护着你,发现有点像汽车加油一样,你的油快要用完了,马上再给你注入一点,再给你往前跑,一直等你跑到终点,OK,所以说类似于这样的一种问题,我们呢,如果我们要自己去写,很难写,也就是说缓存续命的问题。
04:01
各位亲,咱们自己干不好解决,而且你解决了,你上生产真的100%无效吗?100%。抱歉,口误,100%的会有效果,100%的没有问题吗?那么这样呢?我们思考第一个问题,第二个问题就是。我们现在的架构大家请看是个啥,是个单机版,但是我们晓得的啊,一般我们是不是也会出现一种问题叫什么呢。我们是不是干了一种叫master slave,一种集群机制啊,OK吧,甚至我们可能会配一主两层,或者一主一层六台机器,或者是九台机器后面我们这是一个radius集群。那么这个集群的话呢,它就会出现这样一种问题。他做分布式锁什么都好,就是在集群的情况下,可能会出现CP里面的一些小故障,就会导致我们的枷锁失败,理由如下。
05:03
现在我这儿加锁成功,我是不是一般这个叫master加在主机上面,只要我们是一个集群的环境啊各位亲。下面这个是一个。下面假设这是一个集群的环境,这一波同学们没问题吧,那。我们会出现一种什么事?来主机有了以后,是不是会马上会同步这个加锁的这个切给另外的同机,好,那么这个时候将会出现red呢?它的特性是什么概念?AP什么概念?Capp我不解释了啊,AP是分区容错加高可用。那将会出现的问题是我在master上面。我刚刚获得一个锁,我就返回告诉对方说OK了,加锁成功,但是很可能我master还没同步回给silver的时候,不好意思啊,我这淡掉了。
06:04
OK,根据我们的主从复制机制啊,现在就变成主机上是有这把锁,从机上没有,假设我们有这种高可用的哨兵,或者是自动重启无人值守,马上这个master降级变其他。上位,他就变成了新的master,那这个时候的话,由于我刚才还没有同步给我呢,你的master就死了,你死的机器上有你这个信息,有你这张存根,但是我新上台的master并没有,这样就会导致后面来取的时候出现了异常,那么这个异常就是最可怕的一种现象,导致red亦不复制,造成所丢失。主节点master还没来得及把刚刚的set进来的这条的数据给我们的,从节点主机挂掉了,从机上位,但从基上并没有这个数据。那么其他的。
07:04
程序来取的时候,将会出现数据的差异和不一致,这个非常的要命,所以说什么叫AP呢?完整的而言,它是不是为了保证高可用?就牺牲了我的数据一致性,那么恰恰相反,Keepper跟它是相反的r keepper有点类似啊,有主节点和从节点,RA是主机收到了以后马上就拍胸脯说行了,没问题了,你可以走了,可能他还没有同步回呢,但是keepper跟他不一样,Zoo keepper是什么CP,属于什么概念?一致性zoo keepper它呢,有它的选取算法,假设也是这么一个模式啊,Keepper的主节点。集群环境下面,他获得这个key了以后,他先不着急回复啊,他先慢慢的先通知另外两个重节点,保证其他的节点都跟我数据一样了,都一致了,我再返回去给你说OK了,我们这边加锁全部成功了,听懂了吧,那么red呢,是主机OK了,马上返回,有可能导致同机没有。
08:11
但zoo keepper呢,他呢是要全部同步完成了,非常稳妥的告诉对方,我们这边全OK了,那么这个时候zoo keepper就算主节点死了,没关系,从节点的站和主节点的站是不是都有存根一样的存根,那么我从节点上位以后,别人来找也能找到,所以说它们两个的区别就是是AP,是CP,那么理论上而言,哪个更好呢?理论。肯定是如keep,因为它没有义不复制丢失造成所的这种痛苦相对而言要比更稳健。但是。一切皆是平衡。万事万物都是妥协,你keep,你保证一致性了,但是你高可用是不是就下降了?好,我这儿要保证大家什么概念都要去同步完成了,我才通知对方,那么你的高可用性。
09:06
是你的数据一致性上升,你的高可用并发性是不是就下降啊,哎,所以说实际工作当中,我们可能大部分还是用。时代出现这样的一不丢失的问题了,我们呢,再进行后面的修数据,OK,好,这个就是我们现在。8.2的以后还有的两个问题,一个叫缓存续命,一个叫集群上我们自己写的这种东东就不大好使了,那么为了规避这样的风险,为了解决这样的问题,终于我们是不是在社区里面推出了一个我们最牛逼的一个东西,在red集群环境下面,我们自己写的也不OK,是不是才会轮到我们的分布式所得red这种理念下面一个落地的实践叫ready。OK,好。
我来说两句