分散式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同步，還可能是伺服器時間手動調整。總之就是時間回到了過去。針對回退時間的多少可以進行不同的策略改進。一般有以下幾種方案：
- 少量伺服器部署ID生成器例項，關閉NTP伺服器，嚴格管理伺服器。這種方案不需要從程式碼層面解決，完全人治。
- 針對回退時間斷的情況，如閏秒回撥僅回撥了1s，可以在程式碼層面通過判斷暫停一定時間內的ID生成器使用。雖然少了幾秒鐘可用時間，但時鐘正常後，業務即可恢復正常。
if (refusedSeconds <= 5) {
try {
//時間偏差大小小於5ms，則等待兩倍時間
wait(refusedSeconds << 1);//wait
} catch (InterruptedException e) {
e.printStackTrace();
}
currentSecond = getCurrentSecond();
}else {//時鐘回撥較大
//用其他策略修復時鐘問題
}- 例項啟動後，改用記憶體生成時間。該方案為baidu開源的UidGenerator使用的方案，由於例項啟動後，時間不再從伺服器獲取，所以不管伺服器時鐘如何回撥，都影響不了SnowFlake的執行。如下程式碼中lastSecond變數是一個AtomicLong型別，用以代替系統時間
List<Long> uidList = uidProvider.provide(lastSecond.incrementAndGet());- 以上2和3都是解決時鐘
例項執行中→時鐘回撥→計算ID的情況。而例項停機→時鐘回撥→例項重啟→計算ID的情況，可以通過例項啟動的時候，採用未使用過的workerId來完成。只要workerId和此前生成ID的workerId不一致，即便時間戳有誤，所生成的ID也不會重複。UidGenerator採取的就是這種方案，但這種方案又必須依賴一個儲存中心，不管是redis、mysql、zookeeper都可以，但必須儲存著此前使用過的workerId，不能重複。尤其是在分散式部署Id生成器的情況下，更要注意用一個儲存中心解決此問題。 - UidGenerator程式碼可上Githubhttps://github.com/zer0Black/uid-generator檢視
手動配置如何變為自動
其實該處的方案和時鐘回撥的第四個方案是一致的，每次重啟例項的時候，自動的查詢workerId使用，不依賴手動配置。且自查詢的workerId不會重複。方便管理。
參考文件
- UidGenerator文件
- 一口氣說出 9種 分散式ID生成方式，面試官有點懵了
- Leaf——美團點評分散式ID生成系統