是否解决了时钟回拨的问题 about uid-generator HOT 4 CLOSED

* 1解决时钟回拨，时钟回拨后不可发号，必须要等到时钟追赶到回拨前的时间点。
  如果时钟回拨了重启可立马发号，不会重复(重启重新分配的workerID)。

* 2不需要手动配置machineId，通过db table auto increment发号。直到workerID=2^n 用完为止，发号器剧终！

我在犹豫几百万次的重启次数够用了吗，真的要在数据库里面插入几百万次吗，而且这些记录基本没有什么其他用处的

百万次重启次数通常足够，可以根据自己的适用场景设计清理策略，清理不需要的workId，如 workId自增数到达 10w 的倍数触发异步清理之前的数据，其实这个问题是由于没有回收机制导致的，也可以每小时向 mysql 中更新自己workId 所在的记录，每天清理更新时间 < 当前时间 - 24 小时的
上面仅仅是举例，如果发现默认设计不能很好的应对自己的业务场景，推荐考虑根据自身的场景量体裁衣。

from uid-generator.

该方案和雪花ID的最大区别，我认为就是解决了时间回拨问题。

from uid-generator.

• 1解决时钟回拨，时钟回拨后不可发号，必须要等到时钟追赶到回拨前的时间点。
  如果时钟回拨了重启可立马发号，不会重复(重启重新分配的workerID)。
• 2不需要手动配置machineId，通过db table auto increment发号。直到workerID=2^n 用完为止，发号器剧终！

from uid-generator.

* 1解决时钟回拨，时钟回拨后不可发号，必须要等到时钟追赶到回拨前的时间点。
  如果时钟回拨了重启可立马发号，不会重复(重启重新分配的workerID)。

* 2不需要手动配置machineId，通过db table auto increment发号。直到workerID=2^n 用完为止，发号器剧终！

我在犹豫几百万次的重启次数够用了吗，真的要在数据库里面插入几百万次吗，而且这些记录基本没有什么其他用处的

from uid-generator.