00:00
好,同学们,首先到这儿,我们从无到有,从一到八,一点一点一点的迭代、加载、演变、改进,完成了我们的基于red哈希set结构的,能够保证可重入和自动续期功能的自研的red分布式,所写了八个版本。每一个版本。当前是什么样,它有哪些潜在的隐患和问题,最终有变化,迭代改进成什么样,都给同学们进行了详详细细的说明和代码演示。那么如果你能够一级都没有跳过,从头到尾跟着下来,并且也能够写代码成功,那么我认为在这一张上面你应该是有所收获的,可以为自己呢鼓个掌。感谢各位同学能够听到这儿,那么下面不能免俗,还是得给同学们串讲,总结一下我们这八个版本分别是什么情况?好,第一个S的单机板上是OK,上分布式是死翘翘的,前面强调过,如果你snch lock和lock,那么这些呢,它是指满足于同一个Java虚拟机以内,跨机器跨服务它做不到,所以只要是分布式的东西,单机版上几乎无法用,那么接下来呢,我们都清楚,上N以后,上面一个下面一个,上面一个下面一个,100%单机的搞不定,那么我们上了right分布式锁,好,一开始我们所使用的是最经典的,也就说一般中小产所使用的SNX,对吧?那么现在如果用red分布式所。
01:48
要不要用sets,看你们公司业务,如果一般情况下够用,但是如果要写的完善,满足Java。勾UC里面lock接口的规范,用set NX是不够的,我们要h set好,然后完了以后上这个以后我们呢有三大情况,第一个只是加了锁,没有释放锁,对吧?那么除以长的话有可能无法释放,所以必须要在代码层面把它delete掉。接下来呢,假设你加了这个以后,Red服务器会宕机,那么部署了微服务程序的代码根本就走不到final这一块,对吧?同学们可以往前面翻翻啊,我就不再重复啰嗦了,当然是串讲,那么没办法,我们要保证解锁的话呢,这个key没有被删除,所以我们需要有lock key的什么东东,过期时间的设定。那么基于此,我们set NX是不是对标折合进来的,我们大家都清楚,我们这写了这么多对吧?多少多少多少个版本,那么我们要用的是不是一定要set if absent,这个这个这个这个相当于说这两步必须原子操作不能被中断,然后一个命令搞定,并且。
02:56
带过期时间好了,那么接下来由于red的分布式所得T增加了过期时间,那么它们还必须要是同一行,也就是我们这儿所说的放到这个while里面,对吧?有自学来进行反复的抢占,那么最终我们必须要规定只能自己删除自己的锁,不能把别人的锁给干掉,防止张冠李戴,一上了二,二上了三,那搁到这小公司足够了,那么最终我们呢,得到一个非常艰难的一个东东,我们这判断的时候是不是在这个get key如果等于,然后才能删,逻辑上没问题,但是由于这个判断和这个底delete塔不具备原子性,没有办法同意批次完成,中间可能会被加塞尔打断,所以直接上lur脚本,我们呢,把我们的是吗?安洛克,这一段变成了我们的lur脚本,那么这个对标的也就是我们的。
03:56
什么6.0版的这个程序不满,呃,对,那么这个时候我们又发现在这个脚本上又不满足我们的锁的可重入性,所以我们用h set替代了set NX,然后呢,Look也变为了nor脚本的保障,那么同学们还记不记得之前的话呢,我们在这写了以后这一大段,对吧,我们呢也是用诺R脚本,然后我们把它封装进去,然后把这一大段是不是也封装进了我们的对标的这个lock方法里面,其实洛方法也就是调用了我们这一大段脚本,按lock方法也调用我们这大段的脚本,那么就保证加锁和解锁符合GOUC接口的规范,你不要跟我谈路R脚本。
04:40
用户不懂,我们就符合GUUC里面lock接口的规范,给你实现了最经典的lock unlo这两个方法,那么这两个方法为了保证原子性,尤其仅有一个only one来抢占,洛克用洛R脚本保障,安洛克也用洛R脚本保障,OK,那么这张图我相信同学们应该是看得快吐了,应该都明白这个意思,为什么SNX最终会被h set所替代,好,然后最难的是不是要考虑自动续期,如何加个中,那么我们呢,尽量写明白这个意思,就不再引入那些什么叉叉l job我们所采取的原则策略,加锁成功以后。
05:25
在这马上创建一个后台扫描,我们用的是GUUC的什么new time,就是时间任务类啊,这个schedule调度,调度怎么个?调度多久调度一次调度什么?那么30除以30秒钟,每十秒钟来进行一个调度,调度什么呢?来执行一下这个脚本,看看它有没有,如果有加个中,如果没有说明什么返回零,如果要有的话,只能再进行这样的二次三次的检查,续命加重的脚本程序,OK,好,那么同学们,这个就是我们ready分布式所给大家介绍的每一步案例相关的总结感。
我来说两句