请问下时间回拨后是不是不能保证id递增？ about idgenerator HOT 13 CLOSED

当时间回拨后，是不是新ID可以从回拨前的LastTimeTick往后累加，直到时间追平。

from idgenerator.

请问下时间回拨后是不是不能保证id递增？

时间上是递减，同一时间内递增。

from idgenerator.

当时间回拨后，是不是新ID可以从回拨前的LastTimeTick往后累加，直到时间追平。

时间倒流，取历史时间的预留序列数作为新的ID去生成。

from idgenerator.

好的，谢谢，我看了下算法，大概原理明白了，实现的非常巧妙，值得学习。
但是我有一个场景可能会产生问题，我有一个service不停地创建Event ID写入数据库，另外有一个守护进程从数据库中读取 Event 然后Publish到消息队列，但是守护进程读取Event时依赖了ID的递增。如果某一个时刻时间倒流，产生的Event ID不是递增的，但是守护进程不知道时间倒流的情况，可能会导致守护进程从数据库中漏读Event。

from idgenerator.

是不是逻辑中最好不要依赖ID递增这个特性？

from idgenerator.

读取逻辑最好不要依赖ID数值，可以增加一个标记位（是否已读）。

from idgenerator.

Ok，谢谢。

from idgenerator.

读取逻辑最好不要依赖ID数值，可以增加一个标记位（是否已读）。

其实特别希望是在时间回拨后，逻辑上生成的id也是单调递增的，我认为这个需求其实很有意义的。业务上原则上只关心id递增，不用去管时间回拨的问题。雪花算法的一大优点就是单调递增，如果算法不能保证id递增，其实和uuid相比，除了性能好点，其实没有太大区别了。

from idgenerator.

读取逻辑最好不要依赖ID数值，可以增加一个标记位（是否已读）。

其实特别希望是在时间回拨后，逻辑上生成的id也是单调递增的，我认为这个需求其实很有意义的。业务上原则上只关心id递增，不用去管时间回拨的问题。雪花算法的一大优点就是单调递增，如果算法不能保证id递增，其实和uuid相比，除了性能好点，其实没有太大区别了。

时间回拨后，还想新ID是继续增长，也是可以做到，不过这个会增加一些复杂度，比如：ID工具重启时，必须指定一个最新开始值。

from idgenerator.

如果恰好在时间回拨时，又出现ID工具重启，这个雪花漂移算法是不是也会有问题？必须要加个硬条件，ID工具重启后当前时间值必须大于回拨前的时间。

from idgenerator.

如果恰好在时间回拨时，又出现ID工具重启，这个雪花漂移算法是不是也会有问题？必须要加个硬条件，ID工具重启后当前时间值必须大于回拨前的时间。

一般来说，世界级的时间回拨，是秒级。如果这个时候系统重启，ID工具自己暂停了0.5s，另外你的系统启动估计也要一些时间。我相信应该整体上是超过1s钟的。

from idgenerator.

一般世界级时间回拨没有问题，而且这种情况发生的很少。但是我们有些服务直接可能会安装ntp服务，主服务器如果被人为回拨时间，可能会导致所有服务都会回拨。
我只是提个小建议，期望能在回拨时，可以保证id递增。

from idgenerator.

一般世界级时间回拨没有问题，而且这种情况发生的很少。但是我们有些服务直接可能会安装ntp服务，主服务器如果被人为回拨时间，可能会导致所有服务都会回拨。 我只是提个小建议，期望能在回拨时，可以保证id递增。

2个条件：
（1）服务器时间被人为回拨
（2）服务器重启后的时间比上次小
在生产环境，同时发生的概率不高。

如果单纯希望ID递增，需要修改ID生成方法的入口参数，传入上次最大ID值，然后从该值继续。

from idgenerator.