ansoda
ansoda
我也遇到了同样的close后hang住的问题，看能否更新一个版本优化下
当时间回拨后，是不是新ID可以从回拨前的LastTimeTick往后累加，直到时间追平。
好的，谢谢，我看了下算法，大概原理明白了，实现的非常巧妙，值得学习。 但是我有一个场景可能会产生问题，我有一个service不停地创建Event ID写入数据库，另外有一个守护进程从数据库中读取 Event 然后Publish到消息队列，但是守护进程读取Event时依赖了ID的递增。如果某一个时刻时间倒流，产生的Event ID不是递增的，但是守护进程不知道时间倒流的情况，可能会导致守护进程从数据库中漏读Event。
是不是逻辑中最好不要依赖ID递增这个特性？
Ok，谢谢。
> 读取逻辑最好不要依赖ID数值，可以增加一个标记位（是否已读）。 其实特别希望是在时间回拨后，逻辑上生成的id也是单调递增的，我认为这个需求其实很有意义的。业务上原则上只关心id递增，不用去管时间回拨的问题。雪花算法的一大优点就是单调递增，如果算法不能保证id递增，其实和uuid相比，除了性能好点，其实没有太大区别了。
如果恰好在时间回拨时，又出现ID工具重启，这个雪花漂移算法是不是也会有问题？必须要加个硬条件，ID工具重启后当前时间值必须大于回拨前的时间。
一般世界级时间回拨没有问题，而且这种情况发生的很少。但是我们有些服务直接可能会安装ntp服务，主服务器如果被人为回拨时间，可能会导致所有服务都会回拨。 我只是提个小建议，期望能在回拨时，可以保证id递增。
请问下，这个功能现在在开发中么？
I use a lot of mgo in my projects，I want to Implement mgo interface via mongo-go-driver。