分布式唯一ID分配问题

snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。其核心思想是：使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID），最后还有一个符号位，永远是0。

1.第一位，占用1bit，其值始终是0，没有实际作用。

2.时间戳，占用41bit，精确到毫秒，总共可以容纳约140年的时间。

3.工作机器id，占用10bit，其中高位5bit是数据中心ID（datacenterId），低位5bit是工作节点ID（workerId），做多可以容纳1024个节点。

4.序列号，占用12bit，这个值在同一毫秒同一节点上从0开始不断累加，最多可以累加到4095。

同一毫秒的ID数量 = 1024 X 4096 = 4194304

SnowFlake算法的优点：

1.生成ID时不依赖于DB，完全在内存生成，高性能高可用。

2.ID呈趋势递增，后续插入索引树的时候性能较好。

SnowFlake算法的缺点：

1、由于SnowFlake强依赖时间戳，所以时间的变动会造成SnowFlake的算法产生错误。如果某台机器的系统时钟回拨，有可能造成ID冲突，或者ID乱序。在SnowFlake算法中并没有什么有效的解法，仅是抛出异常。时钟回拨涉及两种情况①实例停机→时钟回拨→实例重启→计算ID ②实例运行中→时钟回拨→计算ID

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

Twitter-Snowflake，64位自增ID算法详解

PHP使用SnowFlake算法生成唯一ID