36-ShardingSphere-JDBC-水平分片-分表配置-雪花算法

接下来呢，我们来看一下分布式序列算法，那么分布式序列呢，前面其实我们已经做了一个初步的设置，只不过呢，这个设置我们是在。实题类中设置的，而实题类中设置的这个分布式序列呢，它不是基阿帕奇的she fair gd bc的，它是基于my beat plus的，所以这个是在MY当中呢，我们设置了一个分布式序列，我们来看一下它的源码。这面呢，提到了这个里面用的是一个叫做花法的一个分布式序列，那么我们再来看一看阿奇的DC里面的，里面的分布式呢，其实也有一个算法，就是这个fke算法，好，那么在当中其实还给我们提供了一个算法叫ID。那么在我们的MY当中，其实也有这个UID的算法，所以可见呢，这些其实都是常用的在分布环境下一些生成的算法，那么UID这个其实不是特别建议大家去用，因为如果你对ID了解的话，那么我们知道UID是无序的，而无序的这种数据呢，是不太适合作为主件的，因为在我们的买circle数据库的inno DB的存储引擎当中呢，这个主键啊，如果是无序的，那么对索引字段的插入的效率呢，是有非常大的影响的。

那么在这个里面呢，就建议大家，如果你用的是my circle，那么主键呢，一定要用有序的，所以呢，在这个地方得到的结论就是UUID，因为它是无序的，不太适合作为主见，所以那就只剩下snowfleke了。那接下来呢，我们来介绍一下snowflake snowfleke它实现的原理呢，在sheding fair gd bc当中，以及在MY贝斯plus当中，他们的原理呢，都是一样的，所以呢，我们以这个sheding fair gd b。

那么我们先看前面这个实现动机哈。传统的数据库软件开发当中呢，主件自动生成技术呢，其实是一个基本的需求，那么my circlele呢，它是有自增建的，而Oracle呢，它是有自增序列的，但是我们对数据进行分片之后呢，不同的数据节点生成全局唯一主键呢，就变成了一个非常棘手的问题了，为什么呢？因为同一个逻辑表内的不同的实际表，也就是说我们一个逻辑表可能对应多个不同的实际表，那么不同的实际表之间的自增建呢，它们是没有办法互相感知的，意思呢，就是在我们的serve order0里面的T0表和T1表，它们两个如果都设置了各自的主键自增的话，那么他们个之间是感知不到对方这个主键增加到了哪一个数值的啊，那所以这样的话呢，就会导致我们的数据库当中呢，会出现重复的主键，那它其实有一种非常简便的解决方案，就是约束自增主键的。

初始值和不长什么意思呢？比如说在这个地方，我们可以定义这面的这个。T的这个数据增初始呢是一，然后二话呢，这个就是1357好，那么我们可以规定这个主键的初始值呢是二，然后它的步长也是二，那么它的主键呢，可能就是2468好，这样的话呢，我们说即使这两个没有办法互相感知，但是由于我们约定了初始值和不长，那么他们两个之间呢，就不会发生冲突了，这个呢，就是约定初始值和不长的一个方案，当然了，如果要是结合着这个数据库当中的这两张表来看的话呢，那么我们整个的这个初始值和步长呢，还要做进一步的优化，因为我们要防止这四个表中的逐渐冲突，对不对？好，这是一种解决方案。

好，我们来看一下这个snowflake雪花算法，那么雪花算法它实际上是使用了64个比特位长度的这样的一个二进制数据啊，那它转换成整数的话呢，它其实是一个长整形来表示我们数据的主键。那么取外算法呢，是Twitter公布的一个分布式生成的一个算法，它能够保证不同的进程的重复。以及相同进程的逐渐的有序性。那么它的实现原理呢，就是这个样子的，它一共有64个比特位，那这64个比特位呢。分成12344个部分，那这四个部分呢，分别是在上面这块有一个描述。

叫一比特的符号位，那么这这是一比特的符号位，因为ID嘛，它一定是正数，所以这个符号位呢，永远是零，然后还有41比的时间错位，这41个比特呢，它表示时间，然后接下来呢，是十比特的工作进程。那这十个比特呢，是工作进程，还有12比特的序列号位，那这12个比特呢，是序列号位，好，那么我们先来看符号位，说了横等于零。啊，因为ID呢一般都是正数，好，然后接下来呢，是时间位，41位的时间可以容纳的毫秒数，因为这个是二进制数，所以如果是41位二进制数的话呢，就是二的41次幂，那么一年所使用的毫秒数，一年是365天乘以24小时乘以60分乘以60秒，再乘以1000毫秒，那么我们用二的41次幂除以刚才最终的这个值呢？

那约等于69.73年，那阿帕奇的的雪花算法呢，它的时间纪元是从2016年11月1号开始的，那所以说呢，这个雪花算法呢，我们可以用到2086年，那么2086年以后怎么办呢？那就是未来的事情了哈，那技术可能已经更新迭代很多了，所以说阿奇本身它存不存在都是个未知了，是不是啊，所以这个二零。应该是说能够满足我们的系统要求的，然后接下来呢，就是比特的工作进程位。如果我们是在同一个Java进程内去生成ID的话，那么这个数据呢，是不变的啊，如果换了一个进程的话，那这个数据呢，又可以给他分配另外一个值，默认情况下呢，这个值是零啊。那么接下来呢，就是序列号位，序列号位的话呢，它会在同一个秒内生成不同的ID，如果我们的这个并发访问量特别大，导致这个时间错呢，它是在同一个毫秒内有特别多的ID生成需求的话，那么我们知道在工作进程相同的情况下，在毫秒相同的情况下，如果没有这12比特的序列号位了的话，那么这个ID呢，就会产生冲突，所谓的冲突呢，就是ID一致了，因为一毫ID。

部分的话，那前面肯定是一致的，对不对？好，那怎么样能够让我们的雪花算法在一毫秒内能生成多个ID呢？就是后面这12比特的序列号位了，那么这12比特的序列号位呢，能生成二的12次密ID，也就是说4096个ID，那也就意味着在一个进程的同一毫秒内，我们呢，实际上能生成四千零就是六个ID。下面呢，它是一个总结，这总结呢，就是整个的雪花算法，它呢可以从2016年11月1日开始，一直生成到69.7，三年之后啊都是有效的，然后呢，工作进程数，工作进程数因为这是十个比特位，所以呢二的十次方，那它支持1024个节点。

那生成不碰撞序列的TPSTPS呢，就是每秒的并发量，那么刚才我们提到了每一个毫秒内一个工作进程呢，能生成4096个不碰撞的ID，那么每一秒内呢，就能生成409.6万个不碰撞的ID，所以这个呢就是雪花算法的一个基本的思想，它能够确保我们在分布式环境下生成。唯一的ID。