long 雪花算法_雪花算法：每一片雪花都是独一无二的

标题写得那么文艺，但文字是写技术的。

德国哲学家、数学家莱布尼茨说过一句话：“There are no two identical leaves in the world.”

我想这大概是Twitter为啥把自己的开源分布式 id 生成算法叫做：SnowFlake 算法，中文雪花算法。

顾名思义，就是通过算法能获取到唯一的编号。

这在一般规模应用或者传统企业，都是用不到的。

一般用数据库自增Id或者数据库实现的中心化Id分配，或者GUID、UUID等。

而对于大型互联网公司，这个唯一编号都是刚需。

所以很多国内的互联网公司，如百度、美团、滴滴在Twitter的Scalar SnowFlake ID的基础上开发了Java版、.NET版等，并扩展了很多应用，解决了宕机和时间回拨的编号重复问题，当然了也都开源了，大家可以自行GitHub搜索：滴滴 TinyID、 百度 Uidgenerator、美团 Leaf。

简单说说它的原理吧

Snowflake ID组成结构：正数位(1字节)+ 时间戳(41 字节)+ 机器ID(5 字节)+ 数据中心(5 字节)+ 自增值(12 字节)，总共64 字节组成的一个Long类型。

在Java中Snowflake生成的是Long类型的ID，一个Long类型占8个字节，每个字节占8 字节 ，也就是说一个Long类型占64个 字节 。而.NET中Long类型是System.Int64的一个实例。

第一个bit位(1bit)：Java中long的最高位是符号位代表正负，正数是0，负数是1，一般生成ID都为正数，所以默认为0。

时间戳部分(41bit)：毫秒级的时间，不建议存当前时间戳，而是用(当前时间戳 – 固定开始时间戳)的差值，可以使产生的ID从更小的值开始；41位的时间戳可以使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年

工作机器id(10bit)：也被叫做workId，这个可以灵活配置，机房或者机器号组合都可以。

序列号部分(12bit)，自增值支持同一毫秒内同一个节点可以生成4096个ID

根据这个算法的逻辑，只需要将这个算法用Java/.NET语言实现出来，封装为一个工具方法，那么各个业务应用可以直接使用该工具方法来获取分布式ID，只需保证每个业务应用有自己的工作机器id即可，而不需要单独去搭建一个获取分布式ID的应用。

SnowFlake有什么问题

SnowFlake很好，分布式、去中心化、无第三方依赖。但它并不是完美的，由于SnowFlake强依赖时间戳，所以时间的变动会造成SnowFlake的算法产生错误。

时钟回拨：最常见的问题就是时钟回拨导致的ID重复问题，在SnowFlake算法中并没有什么有效的解法，仅是抛出异常。

时钟回拨涉及两种情况

1、实例停机→时钟回拨→实例重启→计算ID

2、实例运行中→时钟回拨→计算ID

手动配置WorkerId：另一个就是workerId(机器ID)是需要部署时手动配置，而workerId又不能重复。几台实例还好，一旦实例达到一定量级，管理workerId将是一个复杂的操作。