已有的方案：

可大致分為：

完全依賴關系/非關系型數據庫遞增的方案

完全不依賴數據源作為生成因子的UUID

半依賴數據源作為生成因子的snowflake

為什么推薦snowflake？

這個問題，可以從前兩個方案的缺點來講。

完全依賴關系/非關系型數據庫遞增的方案：

關系/非關系的區別細節就不展開了，只說說關系型。它最大的缺點是并發的瓶頸，其次是拓展性的問題，再就是還需要考慮數據庫的可用性。

噢對了高可用也挺難搞的，不是說難度哈，只是這玩意是真滴麻煩啊，因為一般來說也得雙寫部署，不然掛掉一個master怎么辦，對吧？那雙寫之后還需要給master配上中間件吧？噢中間件也需要高可用吧？好吧那最后還需要上個nginx或者keepalived…到了這里回頭一看“完了我只想生成一個ID而已為什么還要增加那么多東西，需要額外考慮那么多東西？真蛋疼”。所以斃掉這個方案！

UUID：

UUID，神奇的東西(我沒仔細研究，所以用“神奇”這個詞來蒙混過去)，無需數據源作為生成因子卻能生成全球唯一ID。屌哇！但是用它作為ID的話還是太大了，16個字節啊，浪費空間不說還影響索引的效率。

不過最大的缺點還不是它的大小，而是它是生成的ID是無序的，但是主流的數據庫的索引數據結構都是B+樹結構，所以你明白了吧。(這里不懂的朋友請自行搜索 B+樹分裂問題 ，我沒有能力在三言兩語內解釋清楚)

所以什么是snowflake？

snowflake 算法是 twitter 開源的分布式 id 生成算法，采用 Scala 語言實現，是把一個 64 位的 long 型的 id，1 個 bit 是不用的，用其中的 41 bits 作為毫秒數，用 10 bits 作為工作機器 id，12 bits 作為序列號。(這句話是復制來的)

snowflake算法生成的ID的結構：

總共64bit，剛好是一個long類型的大小

符號位：符號位是不用的，因為ID只考慮正數。

時間戳：注意是精度為毫秒級的，而不是秒級的。

區域ID：也叫數據中心ID，標識機器所屬的數據中心。

機器ID：配合區域ID，用作定位某區域的機房里的其中一臺機器。

序列號：看到這里你可能已經明白了，時間戳標記了時間，區域和機器ID標記了機器所屬，那么在一個時間單位里，同一臺機器請求多個ID怎么辦？對，所以需要序列號的遞增作為ID的遞增生成因子。

算法思路：

如果是在同一時間單位內，則遞增序列號作為ID生成因子，直至0 ~ 2^12-1 (0到4095)所有數字用完了，或者檢測到時間戳更新了的時候，才將序列號歸零重新遞增。按照這個思路就可以做出理論上并發為 (2^12-1)(2^10)≈4,200,000 的ID生成算法了。很簡單吧。我感覺就并發能力而言，這個算法可以用到死了。

(注意，區域/機器ID不是由snowflake生成的，而是讓各個機器在需要時主動調用該生成算法，在調用時傳入區域/機器ID作為分布式全局唯一ID的生成因子之一。)

算法的實現

測試結果

我的機器性能不足，加上目前只是單線程測試，所以你會看到圖一開頭就幾個sequenceID都是0，那是因為時間戳更新后sequenceID歸零了。

圖二可以看到，單位時間內我機子的性能最多疊加到29。改天再做個多線程測試。完

總結

以上是生活随笔為你收集整理的java 唯一id生成算法_分布式全局唯一ID生成方案之snowflake算法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。