記一次雪花算法遇到的生產(chǎn)事故！
最近生產(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，不應(yīng)該生成重復(fù)的 ID。
大家可以先猜猜是什么原因。
有的同學(xué)可能對(duì)雪花算法不熟悉，這里做個(gè)簡(jiǎn)單的說明。
一、雪花算法
snowflake（雪花算法）：Twitter 開源的分布式 id 生成算法，64 位的 long 型的 id，分為 4 部分：
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ì)遞增的。
不依賴數(shù)據(jù)庫等第三方系統(tǒng)，以服務(wù)的方式部署，穩(wěn)定性更高，生成ID的性能也是非常高的。
可以根據(jù)自身業(yè)務(wù)特性分配bit位，非常靈活。
缺點(diǎn)：
強(qiáng)依賴機(jī)器時(shí)鐘，如果機(jī)器上時(shí)鐘回?fù)埽梢运阉?2017 年閏秒 7:59:60），會(huì)導(dǎo)致發(fā)號(hào)重復(fù)或者服務(wù)會(huì)處于不可用狀態(tài)。
看了上面的關(guān)于雪花算法的簡(jiǎn)短介紹，想必大家能猜出個(gè)一二了。
雪花算法和時(shí)間是強(qiáng)關(guān)聯(lián)的，其中有 41 位是當(dāng)前時(shí)間的時(shí)間戳，
二、排查
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)制來表示：
SH復(fù)制代碼十進(jìn)制表示：2097167233578045440 ?二進(jìn)制表示：0001 1101 0001 1010 1010 0010 0111 1100 1101 1000 0000 0010 0001 0000 0000 0000
找到項(xiàng)目中使用雪花算法的工具類，生成 ID 的時(shí)候有個(gè)判斷邏輯：
當(dāng)
當(dāng)前時(shí)間小于上次的生成時(shí)間就會(huì)返回-1，所以問題就出在這個(gè)邏輯上面。(有的雪花算法是直接拋異常)
SH復(fù)制代碼if (timestamp < this.lastTimestamp) { ?? return -1; }
由于每次 timestamp 都是小于 lastTimeStamp，所以每次都返回了 -1，這也解釋了為什么生成了重復(fù)的 key。
2.2 時(shí)鐘回?fù)芑蛱S
那么問題就聚焦在為什么當(dāng)前時(shí)間還會(huì)小于上次的生成時(shí)間。
下面有種場(chǎng)景可能發(fā)生這種情況：
首先假定當(dāng)前的北京時(shí)間是 9:00:00。另外上次生成 ID 的時(shí)候，服務(wù)器獲取的時(shí)間 lastTimestamp=10:00:00，而現(xiàn)在服務(wù)器獲取的當(dāng)前時(shí)間 timestamp=09:00:00，這就相當(dāng)于服務(wù)器之前是獲取了一個(gè)未來時(shí)間，現(xiàn)在突然跳躍到當(dāng)前時(shí)間。
而這種場(chǎng)景我們稱之為時(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呢？
我們猜測(cè)是不是服務(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è)置：
SH復(fù)制代碼*/10 * * * * /usr/sbin/ntpdate <ip>
另外時(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>
xml復(fù)制代碼ntpdate ?<時(shí)鐘服務(wù)器 IP>
在產(chǎn)生事故之前，我們重啟過服務(wù)器 1。我們推測(cè)服務(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ì)帶了很多問題，比如潤(rùn)秒 問題也會(huì)帶來 1s 時(shí)間的回?fù)堋?/p>
閏秒就是通過給“世界標(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)慢一秒鐘。
為了預(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í)間，從而脫離了對(duì)服務(wù)器時(shí)間的依賴，也就不會(huì)有時(shí)鐘回?fù)艿膯栴}。
重點(diǎn)就是預(yù)生成一批 ID！
Github地址：
SH復(fù)制代碼https://github.com/baidu/uid-generator
四、總結(jié)
本篇通過一次偶發(fā)的生產(chǎn)事故，引出了雪花算法的原理、雪花算法的不足、對(duì)應(yīng)的開源解決方案。
雪花算法強(qiáng)依賴服務(wù)器的時(shí)鐘，如果時(shí)鐘產(chǎn)生了回?fù)埽蜁?huì)造成很多問題。
我們的系統(tǒng)雖然做了 NTP 時(shí)鐘同步，但也不是 100% 可靠，而且潤(rùn)秒這種場(chǎng)景也是出現(xiàn)過很多次。鑒于此，美團(tuán)和百度也有對(duì)應(yīng)的解決方案。
最后，我們的生產(chǎn)環(huán)境也是第一次遇到因 NTP 導(dǎo)致的時(shí)鐘回?fù)埽蚁到y(tǒng)中用到雪花算法的地方并不多，所以目前并沒有采取以上的替換方案。
