需求: 使用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；
