记一次“雪花算法”造成的生产事故的排查记录( 四 ) _雪花算法

而这种场景我们称之为时钟回拨或时钟跳跃。
时钟回拨：服务器时钟可能会因为各种原因发生不准，而网络中会提供 NTP 服务来做时间校准，因此在做校准的时候，服务器时钟就会发生时钟的跳跃或者回拨问题。
2.3 时钟同步
那么服务器为什么会发生时钟回拨或跳跃呢？

我们猜测是不是服务器上的时钟不同步后，又自动进行同步了，前后时间不一致。

首先我们的每台服务器上都安装了 ntpdate 软件，作为 NTP 客户端，会每隔 10 分钟向 NTP 时间服务器同步一次时间。
如下图所示，服务器 1 和服务器 2 部署了应用服务，每隔 10 分钟向时间服务器同步一次时间，来保证服务器 1 和服务器 2 的时间和时间服务器的时间一致。

文章插图

每隔 10 分钟同步的设置：
*/10 * * * * /usr/sbin/ntpdate
另外时间服务器会向 NTP Pool同步时间， NTP Pool 正在为世界各地成百上千万的系统提供服务。它是绝大多数主流Linux发行版和许多网络设备的默认“时间服务器” 。（参考ntppool.org）
那问题就是 NTP 同步出了问题？？
2.4 时钟不同步
我们到服务器上查看了下时间，确实和时钟服务器不同步，早了几分钟。
当我们执行 NTP 同步的命令后，时钟又同步了，也就是说时间回拨了。同步的命令如下：
ntpdate <时钟服务器 IP>
在产生事故之前，我们重启过服务器 1 。我们推测服务器重启后，服务器因网络问题没有正常同步。而在下一次定时同步操作到来之前的这个时间段，我们的后端服务已经出现了因 ID 重复导致的大量异常问题。
这个 NTP 时钟回拨的偶发现象并不常见，但时钟回拨确实会带了很多问题，比如润秒问题也会带来 1s 时间的回拨。
为了预防这种情况的发生，网上也有一些开源解决方案。
三、解决方案
（1）方式一：使用美团 Leaf方案，基于雪花算法。
（2）方式二：使用百度 UidGenerator ，基于雪花算法。
（3）方式三：用 Redis 生成自增的分布式 ID 。弊端是 ID 容易被猜到，有安全风险。
3.1 美团的 Leaf 方案
美团的开源项目 Leaf 的方案：采用依赖 ZooKeeper 的数据存储。如果时钟回拨的时间超过最大容忍的毫秒数阈值，则程序报错；如果在可容忍的范围内， Leaf 会等待时钟同步到最后一次主键生成的时间后再继续工作。
重点就是需要等待时钟同步！

文章插图

3.2 百度 UidGenerator 方案
百度UidGenerator方案不在每次获取 ID 时都实时计算分布式 ID ，而是利用 RingBuffer 数据结构，通过缓存的方式预生成一批唯一 ID 列表，然后通过 incrementAndGet() 方法获取下一次的时间，从而脱离了对服务器时间的依赖，也就不会有时钟回拨的问题。
重点就是预生成一批 ID！
Github地址：
https://github.com/baidu/uid-generator 四、总结
本篇通过一次偶发的生产事故，引出了雪花算法的原理、雪花算法的不足、对应的开源解决方案。
雪花算法因强依赖服务器的时钟，如果时钟产生了回拨，就会造成很多问题。
我们的系统虽然做了 NTP 时钟同步，但也不是 100% 可靠，而且润秒这种场景也是出现过很多次。鉴于此，美团和百度也有对应的解决方案。
最后，我们的生产环境也是第一次遇到因 NTP 导致的时钟回拨，而且系统中用到雪花算法的地方并不多，所以目前并没有采取以上的替换方案。
雪花算法的代码已经上传到 Gitlab：
https://github.com/Jackson0714/PassJava-Platform/blob/master/passjava-common/src/main/java/c