分佈式SnowFlakeID（雪花ID）原理和改進優化

最近在研究分佈式框架的組件和總體設計思路。全部的問題，一旦涉及分佈式難度就呈幾何倍數的提高。包括最多見的ID生成也是，單機狀況下，使用數據庫自增ID、UUID都是簡單易行的選擇

但在分佈式環境下，就須要考慮同業務部署多套之後，ID重複的問題。使用數據庫則數據庫容易成爲瓶頸，使用UUID又沒有順序，數據庫集成又會遇到遞增步長等問題。最後，數據庫（也可以使用redis）號段生成器和snowFlake就成爲了目前分佈式ID生成器的主流

我所知大部分互聯網公司的分佈式ID生成器，其實都是一個網絡服務或集羣，單獨部署。其餘應用程序經過網絡去獲取分佈式的全局惟一ID。使用網絡服務的方式，好處顯而易見，就是方便集中管理，只要生成器設計的沒問題，基本ID就能保證總體趨勢是遞增的。壞處就是獲取效率被明顯下降了

另外針對我司來講，因爲項目的性質，採用分佈式ID生成器，對開發和上線部署及其後期的運維都會帶來必定的麻煩。畢竟上線後，項目的管理權就不在咱們手上了，因此爲了保證分佈式ID生成器的穩定性，儘可能不採起分佈式ID生成中心的策略。因而，留給個人選擇就只剩下了SnowFlakeID（雪花ID）了。

什麼是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個節點）

第三段12位爲毫秒內的計數（12位的計數順序號支持每一個節點每毫秒產生4096個ID序號）

若是按照1024的滿節點（1個節點就是1個部署的服務）計算，每毫秒可生成的ID序號有1024*4096=4194304個，足以知足如今絕大多數的業務狀況

算法的核心以下

((當前時間 - 服務時間) << timestampLeftShift) 
        | (機器ID << workerIdShift) 
        | sequence;

服務時間指的是服務的開發時間，即第一個正式ID產生的時間。因爲SnowFlakeID最長可用69年（由於只有41個bit，41個bit的最大值換算成年就是69年）。因此服務時間越貼近上線時間，則該算法可用時間越長。 其中sequence爲遞增序列，當前時間戳和上一ID生成時間戳一致時，sequence就遞增1，直到4096爲止。

SnowFlake有什麼問題

SnowFlake很好，分佈式、去中心化、無第三方依賴。但它並非完美的，因爲SnowFlake強依賴時間戳，因此時間的變更會形成SnowFlake的算法產生錯誤。

時鐘回撥:最多見的問題就是時鐘回撥致使的ID重複問題，在SnowFlake算法中並無什麼有效的解法，僅是拋出異常。時鐘回撥涉及兩種狀況①實例停機→時鐘回撥→實例重啓→計算ID ②實例運行中→時鐘回撥→計算ID

手動配置:另外一個就是workerId（機器ID）是須要部署時手動配置，而workerId又不能重複。幾臺實例還好，一旦實例達到必定量級，管理workerId將是一個複雜的操做。

如何優化

時鐘回撥改進避免

ID生成器一旦不可用，可能形成全部數據庫相關新增業務都不可用，影響太大。因此時鐘回撥的問題必須解決。

形成時鐘回撥的緣由多種多樣，多是閏秒回撥，多是NTP同步，還多是服務器時間手動調整。總之就是時間回到了過去。針對回退時間的多少能夠進行不一樣的策略改進。通常有如下幾種方案：

1. 少許服務器部署ID生成器實例，關閉NTP服務器，嚴格管理服務器。這種方案不須要從代碼層面解決，徹底人治。
2. 針對回退時間斷的狀況，如閏秒回撥僅回撥了1s，能夠在代碼層面經過判斷暫停必定時間內的ID生成器使用。雖然少了幾秒鐘可用時間，但時鐘正常後，業務便可恢復正常。

if (refusedSeconds <= 5) {
    try {
    //時間誤差大小小於5ms，則等待兩倍時間
		wait(refusedSeconds << 1);//wait
	} catch (InterruptedException e) {
		e.printStackTrace();
	}
    currentSecond = getCurrentSecond();
}else {//時鐘回撥較大
    //用其餘策略修復時鐘問題
}

1. 實例啓動後，改用內存生成時間。該方案爲baidu開源的UidGenerator使用的方案，因爲實例啓動後，時間再也不從服務器獲取，因此無論服務器時鐘如何回撥，都影響不了SnowFlake的執行。以下代碼中lastSecond變量是一個AtomicLong類型，用以代替系統時間

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

1. 以上2和3都是解決時鐘實例運行中→時鐘回撥→計算ID的狀況。而實例停機→時鐘回撥→實例重啓→計算ID的狀況，能夠經過實例啓動的時候，採用未使用過的workerId來完成。只要workerId和此前生成ID的workerId不一致，即使時間戳有誤，所生成的ID也不會重複。UidGenerator採起的就是這種方案，但這種方案又必須依賴一個存儲中心，不論是redis、mysql、zookeeper均可以，但必須存儲着此前使用過的workerId，不能重複。尤爲是在分佈式部署Id生成器的狀況下，更要注意用一個存儲中心解決此問題。
2. UidGenerator代碼可上Githubhttps://github.com/zer0Black/uid-generator查看

手動配置如何變爲自動

其實該處的方案和時鐘回撥的第四個方案是一致的，每次重啓實例的時候，自動的查找workerId使用，不依賴手動配置。且自查找的workerId不會重複。方便管理。

參考文檔

1. UidGenerator文檔
2. 一口氣說出 9種 分佈式ID生成方式，面試官有點懵了
3. Leaf——美團點評分佈式ID生成系統

原文出處：https://www.cnblogs.com/zer0Black/p/12323541.html