leaf 源码分析02 snowflake

1.3.1.3. Snowflake

twitter 开源的一套分布式id生成方法

• 优点：

  • 分布式生成，无单点

  • 趋势递增，生成效率快

  • 生成ID号和时间相关，无规律

• 缺点：

  • 没有全局时钟的情况下，只能保证趋势递增

  • 当通过NTP进行时钟同步时可能会出现重复ID

  • 数据间隙较大

分布式全局唯一ID--SnowFlake算法

  说到全局唯一ID，之前做的一个项目，有遇到类似的需求，会有多并发，但是，又需要类似于id的这么个存在。当时是直接采用的UUID（这个方案实施起来效率最高），当时为了赶进度，就匆匆忙忙的上线了。现在正好来总结一下。

   一般情况，实现全局唯一ID，有三种方案，分别是通过中间件方式、UUID、雪花算法。

    方案一，通过中间件方式，可以是把数据库或者redis缓存作为媒介，从中间件获取ID。这种呢，优点是可以体现全局的递增趋势（优点只能想到这个），缺点呢，倒是一大堆，比如，依赖中间件，假如中间件挂了，就不能提供服务了；依赖中间件的写入和事务，会影响效率；数据量大了的话，你还得考虑部署集群，考虑走代理。这样的话，感觉问题复杂化了

   方案二，通过UUID的方式，java.util.UUID就提供了获取UUID的方法，使用UUID来实现全局唯一ID，优点是操作简单，也能实现全局唯一的效果，缺点呢，就是不能体现全局视野的递增趋势；太长了，UUID是32位，有点浪费；最重要的，是插入的效率低，因为呢，我们使用mysql的话，一般都是B+tree的结构来存储索引，假如是数据库自带的那种主键自增，节点满了，会裂变出新的节点，新节点满了，再去裂变新的节点，这样利用率和效率都很高。而UUID是无序的，会造成中间节点的分裂，也会造成不饱和的节点，插入的效率自然就比较低下了。

    方案三，雪花算法SnowFlake，是推特公司使用的一款通过划分命名空间并行生成的算法，来解决全局唯一ID的需求，类似的还有MongoDB的object_id。雪花算法，是64位二进制，转换十进制，不超过20位。第一位是符号位，一般是不变的0，第二阶梯的是41位的毫秒，第三阶梯是10位的机器ID，第四阶梯是12位的序列号，雪花算法能保证一毫秒内，支持1024*4096个并发，400多W了，对付绝大多数场景，都适用了。优点就是方案一和方案二的不足的反例---不依赖中间件、可以体现趋势递增，且通过第三阶梯的机器ID可以知道是哪一台机器生成的ID，缺点呢，就是因为雪花算法是依赖毫秒，而毫秒又是通过本机来获取的，假如本机的时钟回拨了，那就乱套了，可能会造成ID冲突或者ID乱序。

理论400万/s并发 

根据时间戳，workerId和sequence生成