分布式唯一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

原文地址:https://www.cnblogs.com/xuey/p/13052793.html