本文主要內(nèi)容如下：

前言

最近生產(chǎn)環(huán)境遇到一個(gè)問題：

現(xiàn)象 ：創(chuàng)建工單、訂單等地方，全都創(chuàng)建數(shù)據(jù)失敗。

初步排查 ：報(bào)錯(cuò)信息為duplicate key，意思是保存數(shù)據(jù)的時(shí)候，報(bào)主鍵 id 重復(fù)，而這些 id 都是由雪花算法生成的，按道理來說，雪花算法生成的 ID 是唯一 ID，不應(yīng)該出現(xiàn)重復(fù)的 ID。

大家可以先猜猜是什么原因。

有的同學(xué)可能對雪花算法不熟悉，這里做個(gè)簡單的說明。（熟悉的同學(xué)可以跳到第二個(gè)段落）

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

一、雪花算法

snowflake（雪花算法）：Twitter 開源的分布式 id 生成算法，64 位的 long 型的 id，分為 4 部分：

snowflake 算法

• 1 bit：不用，統(tǒng)一為 0
• 41 bits：毫秒時(shí)間戳，可以表示 69 年的時(shí)間。
• 10 bits：5 bits 代表機(jī)房 id，5 個(gè) bits 代表機(jī)器 id。最多代表 32 個(gè)機(jī)房，每個(gè)機(jī)房最多代表 32 臺(tái)機(jī)器。
• 12 bits：同一毫秒內(nèi)的 id，最多 4096 個(gè)不同 id，自增模式

優(yōu)點(diǎn)：

• 毫秒數(shù)在高位，自增序列在低位，整個(gè)ID都是趨勢遞增的。
• 不依賴數(shù)據(jù)庫等第三方系統(tǒng)，以服務(wù)的方式部署，穩(wěn)定性更高，生成ID的性能也是非常高的。
• 可以根據(jù)自身業(yè)務(wù)特性分配bit位，非常靈活。

缺點(diǎn)：

• 強(qiáng)依賴機(jī)器時(shí)鐘，如果機(jī)器上時(shí)鐘回?fù)埽梢运阉?2017 年閏秒 760 找到相關(guān)問題），會(huì)導(dǎo)致發(fā)號重復(fù)或者服務(wù)會(huì)處于不可用狀態(tài)。

閏秒 就是通過給“世界標(biāo)準(zhǔn)時(shí)間”加（或減）1秒，讓它更接近“太陽時(shí)”。例如，兩者相差超過0.9秒時(shí)，就在23點(diǎn)59分59秒與00點(diǎn)00分00秒之間，插入一個(gè)原本不存在的“23點(diǎn)59分60秒”，來將時(shí)間調(diào)慢一秒鐘。

看了上面的關(guān)于雪花算法的簡短介紹，想必大家能猜出個(gè)一二了。

雪花算法和時(shí)間是強(qiáng)關(guān)聯(lián)的，其中有 41 位是當(dāng)前時(shí)間的時(shí)間戳，那么會(huì)不會(huì)和時(shí)間有關(guān)？

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

二、排查

2.1 雪花算法有什么問題？

既然是雪花算法的問題，那我們就來看下雪花算法出了什么問題：

（1）What：雪花算法生成了重復(fù)的 ID，這些 ID 是什么樣的？

（2）Why：雪花算法為什么生成了重復(fù)的 key

第一個(gè)問題，我們可以通過報(bào)錯(cuò)信息發(fā)現(xiàn)，這個(gè)重復(fù)的 ID 是 -1，這個(gè)就很奇怪了。一般雪花算法生成的唯一 ID 如下所示，我分別用二進(jìn)制和十進(jìn)制來表示：

十進(jìn)制表示：2097167233578045440

二進(jìn)制表示：0001110100011010101000100111110011011000000000100001000000000000

找到項(xiàng)目中使用雪花算法的工具類，生成 ID 的時(shí)候有個(gè)判斷邏輯：

當(dāng)當(dāng)前時(shí)間小于上次的生成時(shí)間就會(huì)返回 -1，所以問題就出在這個(gè)邏輯上面。(有的雪花算法是直接拋異常)

if(timestampthis.lastTimestamp){
return-1;
}

由于每次 timestamp 都是小于 lastTimeStamp，所以每次都返回了 -1 ，這也解釋了為什么生成了重復(fù)的 key。

2.2 時(shí)鐘回?fù)芑蛱S

那么問題就聚焦在為什么當(dāng)前時(shí)間還會(huì)小于上次的生成時(shí)間。

下面有種場景可能發(fā)生這種情況：

首先假定當(dāng)前的北京時(shí)間是 900。另外上次生成 ID 的時(shí)候，服務(wù)器獲取的時(shí)間 lastTimestamp=1000，而現(xiàn)在服務(wù)器獲取的當(dāng)前時(shí)間 timestamp=0900，這就相當(dāng)于服務(wù)器之前是獲取了一個(gè)未來時(shí)間，現(xiàn)在突然跳躍到當(dāng)前時(shí)間。

而這種場景我們稱之為時(shí)鐘回?fù)?/code>或時(shí)鐘跳躍。

時(shí)鐘回?fù)?/strong> ：服務(wù)器時(shí)鐘可能會(huì)因?yàn)楦鞣N原因發(fā)生不準(zhǔn)，而網(wǎng)絡(luò)中會(huì)提供 NTP 服務(wù)來做時(shí)間校準(zhǔn)，因此在做校準(zhǔn)的時(shí)候，服務(wù)器時(shí)鐘就會(huì)發(fā)生時(shí)鐘的跳躍或者回?fù)軉栴}。

2.3 時(shí)鐘同步

那么服務(wù)器為什么會(huì)發(fā)生時(shí)鐘回?fù)芑蛱S呢？

我們猜測是不是服務(wù)器上的時(shí)鐘不同步后，又自動(dòng)進(jìn)行同步了，前后時(shí)間不一致。

首先我們的每臺(tái)服務(wù)器上都安裝了 ntpdate 軟件，作為 NTP 客戶端，會(huì)每隔 10 分鐘向 NTP 時(shí)間服務(wù)器同步一次時(shí)間。

如下圖所示，服務(wù)器 1 和 服務(wù)器 2 部署了應(yīng)用服務(wù)，每隔 10 分鐘向時(shí)間服務(wù)器同步一次時(shí)間，來保證服務(wù)器 1 和服務(wù)器 2 的時(shí)間和時(shí)間服務(wù)器的時(shí)間一致。

圖片

每隔 10 分鐘同步的設(shè)置：

*/10****/usr/sbin/ntpdate

另外時(shí)間服務(wù)器會(huì)向 NTP Pool同步時(shí)間，NTP Pool 正在為世界各地成百上千萬的系統(tǒng)提供服務(wù)。它是絕大多數(shù)主流Linux發(fā)行版和許多網(wǎng)絡(luò)設(shè)備的默認(rèn)“時(shí)間服務(wù)器”。（參考ntppool.org）

那問題就是 NTP 同步出了問題？？

2.4 時(shí)鐘不同步

我們到服務(wù)器上查看了下時(shí)間，確實(shí)和時(shí)鐘服務(wù)器不同步，早了幾分鐘。

當(dāng)我們執(zhí)行 NTP 同步的命令后，時(shí)鐘又同步了，也就是說時(shí)間回?fù)芰恕Ｍ降拿钊缦拢?/p>

ntpdate<時(shí)鐘服務(wù)器?IP>

在產(chǎn)生事故之前，我們重啟過服務(wù)器 1。我們推測服務(wù)器重啟后，服務(wù)器因網(wǎng)絡(luò)問題沒有正常同步 。而在下一次定時(shí)同步操作到來之前的這個(gè)時(shí)間段，我們的后端服務(wù)已經(jīng)出現(xiàn)了因 ID 重復(fù)導(dǎo)致的大量異常問題。

這個(gè) NTP 時(shí)鐘回?fù)艿呐及l(fā)現(xiàn)象并不常見，但時(shí)鐘回?fù)艽_實(shí)會(huì)帶了很多問題，比如潤秒 問題也會(huì)帶來 1s 時(shí)間的回?fù)堋?/p>

為了預(yù)防這種情況的發(fā)生，網(wǎng)上也有一些開源解決方案。

三、解決方案

（1）方式一：使用美團(tuán) Leaf方案，基于雪花算法。

（2）方式二：使用百度 UidGenerator，基于雪花算法。

（3）方式三：用 Redis 生成自增的分布式 ID。弊端是 ID 容易被猜到，有安全風(fēng)險(xiǎn)。

3.1 美團(tuán)的 Leaf 方案

美團(tuán)的開源項(xiàng)目 Leaf 的方案：采用依賴 ZooKeeper 的數(shù)據(jù)存儲(chǔ)。如果時(shí)鐘回?fù)艿臅r(shí)間超過最大容忍的毫秒數(shù)閾值，則程序報(bào)錯(cuò)；如果在可容忍的范圍內(nèi)，Leaf 會(huì)等待時(shí)鐘同步到最后一次主鍵生成的時(shí)間后再繼續(xù)工作 。

重點(diǎn)就是需要等待時(shí)鐘同步！

圖片

3.2 百度 UidGenerator 方案

百度UidGenerator方案不在每次獲取 ID 時(shí)都實(shí)時(shí)計(jì)算分布式 ID，而是利用 RingBuffer 數(shù)據(jù)結(jié)構(gòu)，通過緩存的方式預(yù)生成一批唯一 ID 列表，然后通過 incrementAndGet() 方法獲取下一次的時(shí)間，從而脫離了對服務(wù)器時(shí)間的依賴，也就不會(huì)有時(shí)鐘回?fù)艿膯栴}。

重點(diǎn)就是預(yù)生成一批 ID！

Github地址：

https://github.com/baidu/uid-generator

四、總結(jié)

本篇通過一次偶發(fā)的生產(chǎn)事故，引出了雪花算法的原理、雪花算法的不足、對應(yīng)的開源解決方案。

雪花算法因強(qiáng)依賴服務(wù)器的時(shí)鐘，如果時(shí)鐘產(chǎn)生了回?fù)埽蜁?huì)造成很多問題。

我們的系統(tǒng)雖然做了 NTP 時(shí)鐘同步，但也不是 100% 可靠，而且潤秒這種場景也是出現(xiàn)過很多次。鑒于此，美團(tuán)和百度也有對應(yīng)的解決方案。

最后，我們的生產(chǎn)環(huán)境也是第一次遇到因 NTP 導(dǎo)致的時(shí)鐘回?fù)埽蚁到y(tǒng)中用到雪花算法的地方并不多，所以目前并沒有采取以上的替換方案。

雪花算法的代碼已經(jīng)上傳到 Gitlab：

https://github.com/Jackson0714/PassJava-Platform/blob/master/passjava-common/src/main/java/com/jackson0714/passjava/common/utils/SnowflakeUtilV2.java

---

---

審核編輯 ：李倩