yitter
请问下时间回拨后是不是不能保证id递增？
好的，谢谢，我看了下算法，大概原理明白了，实现的非常巧妙，值得学习。 但是我有一个场景可能会产生问题，我有一个service不停地创建Event ID写入数据库，另外有一个守护进程从数据库中读取 Event 然后Publish到消息队列，但是守护进程读取Event时依赖了ID的递增。如果某一个时刻时间倒流，产生的Event ID不是递增的，但是守护进程不知道时间倒流的情况，可能会导致守护进程从数据库中漏读Event。
读取逻辑最好不要依赖ID数值，可以增加一个标记位（是否已读）。
其实特别希望是在时间回拨后，逻辑上生成的id也是单调递增的，我认为这个需求其实很有意义的。业务上原则上只关心id递增，不用去管时间回拨的问题。雪花算法的一大优点就是单调递增，如果算法不能保证id递增，其实和uuid相比，除了性能好点，其实没有太大区别了。
读取逻辑最好不要依赖ID数值，可以增加一个标记位（是否已读）。
其实特别希望是在时间回拨后，逻辑上生成的id也是单调递增的，我认为这个需求其实很有意义的。业务上原则上只关心id递增，不用去管时间回拨的问题。雪花算法的一大优点就是单调递增，如果算法不能保证id递增，其实和uuid相比，除了性能好点，其实没有太大区别了。
时间回拨后，还想新ID是继续增长，也是可以做到，不过这个会增加一些复杂度，比如：ID工具重启时，必须指定一个最新开始值。
如果恰好在时间回拨时，又出现ID工具重启，这个雪花漂移算法是不是也会有问题？必须要加个硬条件，ID工具重启后当前时间值必须大于回拨前的时间。
一般来说，世界级的时间回拨，是秒级。如果这个时候系统重启，ID工具自己暂停了0.5s，另外你的系统启动估计也要一些时间。我相信应该整体上是超过1s钟的。
一般世界级时间回拨没有问题，而且这种情况发生的很少。但是我们有些服务直接可能会安装ntp服务，主服务器如果被人为回拨时间，可能会导致所有服务都会回拨。 我只是提个小建议，期望能在回拨时，可以保证id递增。
一般世界级时间回拨没有问题，而且这种情况发生的很少。但是我们有些服务直接可能会安装ntp服务，主服务器如果被人为回拨时间，可能会导致所有服务都会回拨。 我只是提个小建议，期望能在回拨时，可以保证id递增。
2个条件： （1）服务器时间被人为回拨 （2）服务器重启后的时间比上次小 在生产环境，同时发生的概率不高。
如果单纯希望ID递增，需要修改ID生成方法的入口参数，传入上次最大ID值，然后从该值继续。