snowflake UUID, workerId 生成策略

需求: 使用snowflake,我们知道snowflake 是利用时间天然的自增,使产生的UUID 不一样。 但是我们避免不了 时间的回拨,这就会导致snowflake 产生的UUID 是有重复的。 当我们使用UUID 作为·DB 的主键的时候,问题就来了,UUID 重复了怎么办? 。 

前提: 1. 理解snowflake 的生成 UUID 策略。

         2. Baidu UUID 生成策略最好读下源码 

         3. 唯一有时间回拨的问题是在 jvm 重启的时候,如果这个jvm 一直运行没有重启,时间回拨,对UUID 的产生是不产生影响的。这点得看看baidu UUID 源码才可理解 

snowflake 一共 64bit, 分成5 个部分: sign (正负), timestamp, workerId, datacenter Id, sequenceId.  datacenterId 很少,所以预留的位数很低,sequenceId 是和并发量有关系。当sequenceId, datacenterId,的位数都确定了之后,可以使用的位数空间就只有timestamp 和 workerId, 现在我们把timestamp 按照秒来计算,那么workerId 使用的空间是 18位 到 22位左右。 也就是 2的18次方到 2 的22 次方之间。也就是26万到 400万之间。

那么workerId 利用的空间最大, 如何保证UUID 一定不会产生重复呢? 即使在时间产生严重的回拨的时候。

经过同事的讲解,觉得使用数组缓存是可以解决的,但是这里面的状态是需要存储的,所以可以存储在DB里面,可以提供 workerId 生成 服务,专门提供workerId。

大概思路是这样:

1. 大概计算下一共需要多少实例要使用UUID,比如有1000个,是不是很多了?

2. 比如有100万个workerId 可以供使用,那么每个 实例会分配到1000个。 比如实例A 的workerId 的范围是 1 - 1000, 实例 B 的workerId 的范围 是 1001-2000, 实例C 的wokerId 是 2001 - 3000, 以此类推。 

3. 我们知道 百度UUID 是存在 ringbuffer 的缓存里面的,那么baidu UUID  生成策略就不回有时间回拨问题,我们主要解决的是 当jvm 重启,而且产生时间回拨的时候,就会有可能产生重复的ID。


比如,instance A 启动的第一次,分配的workerId 是1, timestamp 是null。

instance A 启动第二次的时候,分配的workerId 是2,timestamp 是null, 但是会把第二�次启动的开始时间赋值给第一次 启动的timetamp, 

instance A 启动第三次的时候,分配的workerId 是3, timestamp是null, 但是会把第三次启动的开始时间赋值给第二次启动的timestamp。 

以此类推,一直到 比如 重新启动999次的时候,然后,在从第一次开始。一直轮训。

以后每次启动的timestamp,都对应大于 分配到的workerId 的时间。 同时每次轮训都会同步 wokerId 对应的时间戳。

那么 这个时候会产生重复的UUID 的概率是多少呢? 暂时没有办法计算,个人的觉得,应该是0.

第一:  时间同步, 相差的时间有多少? 是秒,还是时,还是天,个人经验是 秒。

第二: 从workerId 1, 轮训到wokerId 100 (比如分配给这个jvm的一共是100个), 要经历过久? 我想生产线上重启100次的话,需要很久,远远大于时间回拨的误差。

所以我觉得产生重复ID 的概率 为0;

你可能感兴趣的:(snowflake UUID, workerId 生成策略)