什么是分布式SnowFlakeID？如何優(yōu)化SnowFlakeID？這些問題可能是我們?nèi)粘９ぷ鲿姷降?。通過這些問題，希望你能收獲更多。下面是揭開這些問題的詳細(xì)內(nèi)容。

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、小程序定制開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了港南免費(fèi)建站歡迎大家使用！

什么是SnowFlakeID

SnowFlake是twitter公司內(nèi)部分布式項目采用的ID生成算法，開源后廣受國內(nèi)大廠的好評。由這種算法生成的ID，我們就叫做SnowFlakeID

SnowFlakeID的大的特性就是天然去中心化，通過時間戳、工作機(jī)器編號兩個變量進(jìn)行配置后，通過SnowFlake算法會生成唯一的遞增ID。在任何機(jī)器上，只要保證工作機(jī)器編號不同，就可以確保生成的ID唯一，且整體趨勢是遞增的

Snowflake的結(jié)構(gòu)如下(每部分用-分開):

0 - 0000000000 0000000000 0000000000 0000000000 0 - 0000000000 - 000000000000

第一段1位為未使用，永遠(yuǎn)固定為0

第二段41位為毫秒級時間(41位的長度可以使用69年)

第三段10位為workerId(10位的長度最多支持部署1024個節(jié)點(diǎn)）

第三段12位為毫秒內(nèi)的計數(shù)（12位的計數(shù)順序號支持每個節(jié)點(diǎn)每毫秒產(chǎn)生4096個ID序號）

如果按照1024的滿節(jié)點(diǎn)（1個節(jié)點(diǎn)就是1個部署的服務(wù)）計算，每毫秒可生成的ID序號有1024*4096=4194304個，足以滿足現(xiàn)在絕大多數(shù)的業(yè)務(wù)情況

算法的核心如下

 ((當(dāng)前時間 - 服務(wù)時間) << timestampLeftShift) 
     | (機(jī)器ID << workerIdShift) 
     | sequence;

服務(wù)時間指的是服務(wù)的開發(fā)時間，即第一個正式ID產(chǎn)生的時間。由于SnowFlakeID最長可用69年（因為只有41個bit，41個bit的大值換算成年就是69年）。所以服務(wù)時間越貼近上線時間，則該算法可用時間越長。
其中sequence為遞增序列，當(dāng)前時間戳和上一ID生成時間戳一致時，sequence就遞增1，直到4096為止。

SnowFlake有什么問題

SnowFlake很好，分布式、去中心化、無第三方依賴。但它并不是完美的，由于SnowFlake強(qiáng)依賴時間戳，所以時間的變動會造成SnowFlake的算法產(chǎn)生錯誤。

時鐘回?fù)?/strong>:最常見的問題就是時鐘回?fù)軐?dǎo)致的ID重復(fù)問題，在SnowFlake算法中并沒有什么有效的解法，僅是拋出異常。時鐘回?fù)苌婕皟煞N情況①實(shí)例停機(jī)→時鐘回?fù)堋鷮?shí)例重啟→計算ID ②實(shí)例運(yùn)行中→時鐘回?fù)堋嬎鉏D

手動配置:另一個就是workerId（機(jī)器ID）是需要部署時手動配置，而workerId又不能重復(fù)。幾臺實(shí)例還好，一旦實(shí)例達(dá)到一定量級，管理workerId將是一個復(fù)雜的操作。

如何優(yōu)化

時鐘回?fù)芨倪M(jìn)避免

ID生成器一旦不可用，可能造成所有數(shù)據(jù)庫相關(guān)新增業(yè)務(wù)都不可用，影響太大。所以時鐘回?fù)艿膯栴}必須解決。

造成時鐘回?fù)艿脑蚨喾N多樣，可能是閏秒回?fù)?，可能是NTP同步，還可能是服務(wù)器時間手動調(diào)整?？傊褪菚r間回到了過去。針對回退時間的多少可以進(jìn)行不同的策略改進(jìn)。一般有以下幾種方案：

1. 少量服務(wù)器部署ID生成器實(shí)例，關(guān)閉NTP服務(wù)器，嚴(yán)格管理服務(wù)器。這種方案不需要從代碼層面解決，完全人治。
2. 針對回退時間斷的情況，如閏秒回?fù)軆H回?fù)芰?s，可以在代碼層面通過判斷暫停一定時間內(nèi)的ID生成器使用。雖然少了幾秒鐘可用時間，但時鐘正常后，業(yè)務(wù)即可恢復(fù)正常。

if (refusedSeconds <= 5) {
   try {
   //時間偏差大小小于5ms，則等待兩倍時間
     wait(refusedSeconds << 1);//wait
   } catch (InterruptedException e) {
     e.printStackTrace();
   }
   currentSecond = getCurrentSecond();
}else {//時鐘回?fù)茌^大
   //用其他策略修復(fù)時鐘問題
}

1. 實(shí)例啟動后，改用內(nèi)存生成時間。該方案為baidu開源的UidGenerator使用的方案，由于實(shí)例啟動后，時間不再從服務(wù)器獲取，所以不管服務(wù)器時鐘如何回?fù)?，都影響不了SnowFlake的執(zhí)行。如下代碼中l(wèi)astSecond變量是一個AtomicLong類型，用以代替系統(tǒng)時間

 List<Long> uidList = uidProvider.provide(lastSecond.incrementAndGet());

1. 以上2和3都是解決時鐘實(shí)例運(yùn)行中→時鐘回?fù)堋嬎鉏D的情況。而實(shí)例停機(jī)→時鐘回?fù)堋鷮?shí)例重啟→計算ID的情況，可以通過實(shí)例啟動的時候，采用未使用過的workerId來完成。只要workerId和此前生成ID的workerId不一致，即便時間戳有誤，所生成的ID也不會重復(fù)。UidGenerator采取的就是這種方案，但這種方案又必須依賴一個存儲中心，不管是redis、mysql、zookeeper都可以，但必須存儲著此前使用過的workerId，不能重復(fù)。尤其是在分布式部署Id生成器的情況下，更要注意用一個存儲中心解決此問題。

以上就是SnowFlakeID以及優(yōu)化方法的詳細(xì)內(nèi)容了，看完之后是否有所收獲呢？如果想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊！

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

網(wǎng)頁標(biāo)題：什么是分布式SnowFlakeID？如何優(yōu)化SnowFlakeID？-創(chuàng)新互聯(lián)
分享鏈接：http://jinyejixie.com/article42/dephec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供移動網(wǎng)站建設(shè)、用戶體驗、企業(yè)建站、標(biāo)簽優(yōu)化、ChatGPT、外貿(mào)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)