Snowflake生成全局惟一ID的改进

为何要改进Twitter_Snowflake算法呢？开始我是以为原来的设计可能会生成的ID长度不是固定的，和设置的起始时间也有关系，并且服务还要配置这个起始时间，根据当前时间减去起始时间放入41位的时间戳里面，因此生成的ID的长度依赖于这个起始时间，从使用者的角度，可用性不是很清晰。我想生成的ID是长度固定的，否则在用户使用来讲会很奇怪。

由于由于最大2的63次方-1，是个18位数 我看最小的18位是 ：

1101111000 0010110110 1011001110 1001110110 0100000000 0000000000
这个数还不到63位，因此在64位数前面的01就能肯定位数啦。

还有原来设置了workId和datacenterId，每一个占据了5位，能够用于配置多机房的某个机器，那就是32个机房，每一个机房配置32台机器，这样我感受不灵活，好比，根据业务发展，就是有的机房须要配置40台，可是有的机房就是只须要5台，因此我以为这10位合并一下，能够表示1024台机器，可是至于什么机房的哪一台机器，这个关系能够配置在其余地方，在发号器里面配置Id，将这两块的逻辑解偶，考虑到通常中小企业也不会有那么多台机器要配置吧，我以为7位128就已经够了，除去去了前面的01占位符，保持12位的序列不变，那么时间戳位数就有了43位，比起原来的69年*2*2，因此有这个时间的范围，去掉原来的起始时间设置也是合理的。

而后如下这个类的属性的定义就是以下了：

而后主要的实现逻辑：

/**
 * 改过的SnowFlake的结构以下(每部分用-分开):
 * 01 - 0000000000 0000000000 0000000000 0000000000 000 - 0000000 - 000000000000 <br>
 * 1位标识，最高位是0<br>
 * 标识位后的1肯定位数
 * 41位时间截(毫秒级)，注意，43位时间截不是存储当前时间的时间截 69*2*2 年
 * 7位的数据机器位，来肯定是一台机器，128台通常也够用啦
 * 12位序列，毫秒内的计数，12位的计数顺序号支持每一个节点每毫秒(同一机器，同一时间截)产生4096个ID序号<br>
 * 加起来恰好64位，为一个Long型。
 */

git地址：https://github.com/woshiyexinjie/zootopia