您好,登錄后才能下訂單哦!
什么是分布式SnowFlakeID?如何優(yōu)化SnowFlakeID?這些問題可能是我們日常工作會見到的。通過這些問題,希望你能收獲更多。下面是揭開這些問題的詳細內容。
SnowFlake是twitter公司內部分布式項目采用的ID生成算法,開源后廣受國內大廠的好評。由這種算法生成的ID,我們就叫做SnowFlakeID
SnowFlakeID的最大的特性就是天然去中心化,通過時間戳、工作機器編號兩個變量進行配置后,通過SnowFlake算法會生成唯一的遞增ID。在任何機器上,只要保證工作機器編號不同,就可以確保生成的ID唯一,且整體趨勢是遞增的
Snowflake的結構如下(每部分用-分開):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 0000000000 - 000000000000
第一段1位為未使用,永遠固定為0
第二段41位為毫秒級時間(41位的長度可以使用69年)
第三段10位為workerId(10位的長度最多支持部署1024個節(jié)點)
第三段12位為毫秒內的計數(shù)(12位的計數(shù)順序號支持每個節(jié)點每毫秒產生4096個ID序號)
如果按照1024的滿節(jié)點(1個節(jié)點就是1個部署的服務)計算,每毫秒可生成的ID序號有1024*4096=4194304個,足以滿足現(xiàn)在絕大多數(shù)的業(yè)務情況
算法的核心如下
((當前時間 - 服務時間) << timestampLeftShift)
| (機器ID << workerIdShift)
| sequence;
服務時間指的是服務的開發(fā)時間,即第一個正式ID產生的時間。由于SnowFlakeID最長可用69年(因為只有41個bit,41個bit的最大值換算成年就是69年)。所以服務時間越貼近上線時間,則該算法可用時間越長。
其中sequence為遞增序列,當前時間戳和上一ID生成時間戳一致時,sequence就遞增1,直到4096為止。
SnowFlake很好,分布式、去中心化、無第三方依賴。但它并不是完美的,由于SnowFlake強依賴時間戳,所以時間的變動會造成SnowFlake的算法產生錯誤。
時鐘回撥:最常見的問題就是時鐘回撥導致的ID重復問題,在SnowFlake算法中并沒有什么有效的解法,僅是拋出異常。時鐘回撥涉及兩種情況①實例停機→時鐘回撥→實例重啟→計算ID ②實例運行中→時鐘回撥→計算ID
手動配置:另一個就是workerId(機器ID)是需要部署時手動配置,而workerId又不能重復。幾臺實例還好,一旦實例達到一定量級,管理workerId將是一個復雜的操作。
ID生成器一旦不可用,可能造成所有數(shù)據(jù)庫相關新增業(yè)務都不可用,影響太大。所以時鐘回撥的問題必須解決。
造成時鐘回撥的原因多種多樣,可能是閏秒回撥,可能是NTP同步,還可能是服務器時間手動調整??傊褪菚r間回到了過去。針對回退時間的多少可以進行不同的策略改進。一般有以下幾種方案:
if (refusedSeconds <= 5) {
try {
//時間偏差大小小于5ms,則等待兩倍時間
wait(refusedSeconds << 1);//wait
} catch (InterruptedException e) {
e.printStackTrace();
}
currentSecond = getCurrentSecond();
}else {//時鐘回撥較大
//用其他策略修復時鐘問題
}
List<Long> uidList = uidProvider.provide(lastSecond.incrementAndGet());
實例運行中→時鐘回撥→計算ID
的情況。而實例停機→時鐘回撥→實例重啟→計算ID
的情況,可以通過實例啟動的時候,采用未使用過的workerId來完成。只要workerId和此前生成ID的workerId不一致,即便時間戳有誤,所生成的ID也不會重復。UidGenerator采取的就是這種方案,但這種方案又必須依賴一個存儲中心,不管是redis、mysql、zookeeper都可以,但必須存儲著此前使用過的workerId,不能重復。尤其是在分布式部署Id生成器的情況下,更要注意用一個存儲中心解決此問題。
免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經查實,將立刻刪除涉嫌侵權內容。