記一次 “雪花算法” 造成的生產事故的排查記錄

官網：www.passjava.cn

你好，我是悟空。

本文主要內容如下：

前言

最近生產環境遇到一個問題：

現象：創建工單、訂單等地方，全都創建數據失敗。

初步排查：報錯信息爲duplicate key，意思是保存數據的時候，報主鍵 id 重複，而這些 id 都是由雪花算法生成的，按道理來說，雪花算法生成的 ID 是唯一 ID，不應該出現重複的 ID。

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

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

一、雪花算法

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

snowflake 算法

優點：

缺點：

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

看了上面的關於雪花算法的簡短介紹，想必大家能猜出個一二了。

雪花算法和時間是強關聯的，其中有 41 位是當前時間的時間戳，那麼會不會和時間有關？

二、排查

2.1 雪花算法有什麼問題？

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

（1）What：雪花算法生成了重複的 ID，這些 ID 是什麼樣的？

（2）Why：雪花算法爲什麼生成了重複的 key

第一個問題，我們可以通過報錯信息發現，這個重複的 ID 是 -1，這個就很奇怪了。一般雪花算法生成的唯一 ID 如下所示，我分別用二進制和十進制來表示：

十進制表示：2097167233578045440

二進制表示：0001 1101 0001 1010 1010 0010 0111 1100 1101 1000 0000 0010 0001 0000 0000 0000

找到項目中使用雪花算法的工具類，生成 ID 的時候有個判斷邏輯：

當當前時間小於上次的生成時間就會返回 -1，所以問題就出在這個邏輯上面。(有的雪花算法是直接拋異常)

if (timestamp < this.lastTimestamp) {
   return -1;
}

由於每次 timestamp 都是小於 lastTimeStamp，所以每次都返回了 -1，這也解釋了爲什麼生成了重複的 key。

2.2 時鐘回撥或跳躍

那麼問題就聚焦在爲什麼當前時間還會小於上次的生成時間。

下面有種場景可能發生這種情況：

首先假定當前的北京時間是 9:00:00。另外上次生成 ID 的時候，服務器獲取的時間 lastTimestamp=10:00:00，而現在服務器獲取的當前時間 timestamp=09:00:00，這就相當於服務器之前是獲取了一個未來時間，現在突然跳躍到當前時間。

而這種場景我們稱之爲時鐘回撥或時鐘跳躍。

時鐘回撥：服務器時鐘可能會因爲各種原因發生不準，而網絡中會提供 NTP 服務來做時間校準，因此在做校準的時候，服務器時鐘就會發生時鐘的跳躍或者回撥問題。

2.3 時鐘同步

那麼服務器爲什麼會發生時鐘回撥或跳躍呢？

我們猜測是不是服務器上的時鐘不同步後，又自動進行同步了，前後時間不一致。

首先我們的每臺服務器上都安裝了 ntpdate 軟件，作爲 NTP 客戶端，會每隔 10 分鐘向 NTP 時間服務器同步一次時間。

如下圖所示，服務器 1 和 服務器 2 部署了應用服務，每隔 10 分鐘向時間服務器同步一次時間，來保證服務器 1 和服務器 2 的時間和時間服務器的時間一致。

每隔 10 分鐘同步的設置：

*/10 * * * * /usr/sbin/ntpdate <ip>

另外時間服務器會向 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/com/jackson0714/passjava/common/utils/SnowflakeUtilV2.java

參考資料：

https://time.geekbang.org/dailylesson/detail/100075739

https://blog.csdn.net/liangcsdn111/article/details/126103041

https://www.jianshu.com/p/291110ca60fc

關於我

8 年互聯網開發經驗，擅長微服務、分佈式、架構設計。目前在一家大型上市公司從事基礎架構和性能優化工作。

InfoQ 簽約作者、藍橋簽約作者、阿里雲專家博主、51CTO 紅人。

我是悟空，努力變強，變身超級賽亞人！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/i9zRoDeuo2poPizlmpjPBA

猜你喜歡