00:00
接下来呢,我们来看一下分布式序列算法,那么分布式序列呢,前面其实我们已经做了一个初步的设置,只不过呢,这个设置我们是在。实题类中设置的,而实题类中设置的这个分布式序列呢,它不是基阿帕奇的she fair gd bc的,它是基于my beat plus的,所以这个是在MY当中呢,我们设置了一个分布式序列,我们来看一下它的源码。这面呢,提到了这个里面用的是一个叫做花法的一个分布式序列,那么我们再来看一看阿奇的DC里面的,里面的分布式呢,其实也有一个算法,就是这个fke算法,好,那么在当中其实还给我们提供了一个算法叫ID。那么在我们的MY当中,其实也有这个UID的算法,所以可见呢,这些其实都是常用的在分布环境下一些生成的算法,那么UID这个其实不是特别建议大家去用,因为如果你对ID了解的话,那么我们知道UID是无序的,而无序的这种数据呢,是不太适合作为主件的,因为在我们的买circle数据库的inno DB的存储引擎当中呢,这个主键啊,如果是无序的,那么对索引字段的插入的效率呢,是有非常大的影响的。
01:37
那么在这个里面呢,就建议大家,如果你用的是my circle,那么主键呢,一定要用有序的,所以呢,在这个地方得到的结论就是UUID,因为它是无序的,不太适合作为主见,所以那就只剩下snowfleke了。那接下来呢,我们来介绍一下snowflake snowfleke它实现的原理呢,在sheding fair gd bc当中,以及在MY贝斯plus当中,他们的原理呢,都是一样的,所以呢,我们以这个sheding fair gd b。
02:12
那么我们先看前面这个实现动机哈。传统的数据库软件开发当中呢,主件自动生成技术呢,其实是一个基本的需求,那么my circlele呢,它是有自增建的,而Oracle呢,它是有自增序列的,但是我们对数据进行分片之后呢,不同的数据节点生成全局唯一主键呢,就变成了一个非常棘手的问题了,为什么呢?因为同一个逻辑表内的不同的实际表,也就是说我们一个逻辑表可能对应多个不同的实际表,那么不同的实际表之间的自增建呢,它们是没有办法互相感知的,意思呢,就是在我们的serve order0里面的T0表和T1表,它们两个如果都设置了各自的主键自增的话,那么他们个之间是感知不到对方这个主键增加到了哪一个数值的啊,那所以这样的话呢,就会导致我们的数据库当中呢,会出现重复的主键,那它其实有一种非常简便的解决方案,就是约束自增主键的。
03:17
初始值和不长什么意思呢?比如说在这个地方,我们可以定义这面的这个。T的这个数据增初始呢是一,然后二话呢,这个就是1357好,那么我们可以规定这个主键的初始值呢是二,然后它的步长也是二,那么它的主键呢,可能就是2468好,这样的话呢,我们说即使这两个没有办法互相感知,但是由于我们约定了初始值和不长,那么他们两个之间呢,就不会发生冲突了,这个呢,就是约定初始值和不长的一个方案,当然了,如果要是结合着这个数据库当中的这两张表来看的话呢,那么我们整个的这个初始值和步长呢,还要做进一步的优化,因为我们要防止这四个表中的逐渐冲突,对不对?好,这是一种解决方案。
04:13
好,我们来看一下这个snowflake雪花算法,那么雪花算法它实际上是使用了64个比特位长度的这样的一个二进制数据啊,那它转换成整数的话呢,它其实是一个长整形来表示我们数据的主键。那么取外算法呢,是Twitter公布的一个分布式生成的一个算法,它能够保证不同的进程的重复。以及相同进程的逐渐的有序性。那么它的实现原理呢,就是这个样子的,它一共有64个比特位,那这64个比特位呢。分成12344个部分,那这四个部分呢,分别是在上面这块有一个描述。
05:06
叫一比特的符号位,那么这这是一比特的符号位,因为ID嘛,它一定是正数,所以这个符号位呢,永远是零,然后还有41比的时间错位,这41个比特呢,它表示时间,然后接下来呢,是十比特的工作进程。那这十个比特呢,是工作进程,还有12比特的序列号位,那这12个比特呢,是序列号位,好,那么我们先来看符号位,说了横等于零。啊,因为ID呢一般都是正数,好,然后接下来呢,是时间位,41位的时间可以容纳的毫秒数,因为这个是二进制数,所以如果是41位二进制数的话呢,就是二的41次幂,那么一年所使用的毫秒数,一年是365天乘以24小时乘以60分乘以60秒,再乘以1000毫秒,那么我们用二的41次幂除以刚才最终的这个值呢?
06:06
那约等于69.73年,那阿帕奇的的雪花算法呢,它的时间纪元是从2016年11月1号开始的,那所以说呢,这个雪花算法呢,我们可以用到2086年,那么2086年以后怎么办呢?那就是未来的事情了哈,那技术可能已经更新迭代很多了,所以说阿奇本身它存不存在都是个未知了,是不是啊,所以这个二零。应该是说能够满足我们的系统要求的,然后接下来呢,就是比特的工作进程位。如果我们是在同一个Java进程内去生成ID的话,那么这个数据呢,是不变的啊,如果换了一个进程的话,那这个数据呢,又可以给他分配另外一个值,默认情况下呢,这个值是零啊。那么接下来呢,就是序列号位,序列号位的话呢,它会在同一个秒内生成不同的ID,如果我们的这个并发访问量特别大,导致这个时间错呢,它是在同一个毫秒内有特别多的ID生成需求的话,那么我们知道在工作进程相同的情况下,在毫秒相同的情况下,如果没有这12比特的序列号位了的话,那么这个ID呢,就会产生冲突,所谓的冲突呢,就是ID一致了,因为一毫ID。
07:32
部分的话,那前面肯定是一致的,对不对?好,那怎么样能够让我们的雪花算法在一毫秒内能生成多个ID呢?就是后面这12比特的序列号位了,那么这12比特的序列号位呢,能生成二的12次密ID,也就是说4096个ID,那也就意味着在一个进程的同一毫秒内,我们呢,实际上能生成四千零就是六个ID。下面呢,它是一个总结,这总结呢,就是整个的雪花算法,它呢可以从2016年11月1日开始,一直生成到69.7,三年之后啊都是有效的,然后呢,工作进程数,工作进程数因为这是十个比特位,所以呢二的十次方,那它支持1024个节点。
08:21
那生成不碰撞序列的TPSTPS呢,就是每秒的并发量,那么刚才我们提到了每一个毫秒内一个工作进程呢,能生成4096个不碰撞的ID,那么每一秒内呢,就能生成409.6万个不碰撞的ID,所以这个呢就是雪花算法的一个基本的思想,它能够确保我们在分布式环境下生成。唯一的ID。
我来说两句