5 大分散式 ID 生成器優缺點簡單對比

點選上方“業餘草”，選擇“置頂公眾號”

第一時間獲取技術乾貨和業界資訊！

 

首選，不管是不是分散式系統，都有 ID 唯一的使用場景。而在分散式場景下，對 ID 的唯一性要求更嚴格！

常見的，我們上淘寶買東西的訂單 ID，就是一種分散式 ID。淘寶，前期的訂單 id 好像是 14 位，現在好像已經是 16 位，或者 18 位了吧。

以我們公司的訂單 ID 為例，它有這幾個特點。

1. ID 全域性唯一，不會重複

2. ID 的增長支援分散式使用

3. ID 要方便好記，並且通過 ID 能大概看出是什麼時間建立的訂單

4. 訂單 ID 最好還能追蹤到銷售員，或下單使用者的 ID 等

5. 增長的訂單 ID 還不能讓競爭對手發現你每天的業務量

針對第五項，淺顯的問題就是不能讓非核心運營者知道每天的訂單量等資訊。如果 ID 是連續的，惡意使用者的扒取工作就非常容易做了，直接按照順序下載指定 URL 即可；如果是訂單號就更危險了，競對可以直接知道我們一天的訂單量。所以在一些應用場景下，會需要 ID 無規則、不規則。

所以，設計一個好的分散式 ID 生成器並不是那麼容易的。於是網上也有很多大公司開源這類分散式 ID 生成器。我今天就抽個時間，扯一扯它們之間的不同點吧。

說到，分散式 ID，我們首選想到的可能就是 UUID 了。

UUID

UUID (Universally Unique Identifier) 的標準型式包含 32 個 16 進位制數字，以連字號分為五段，形式為 8-4-4-4-12 的 36 個字元，示例：550e8400-e29b-41d4-a716-446655440000，到目前為止業界一共有 5 種方式生成 UUID。

UUID 的優點：效能非常高：本地生成，沒有網路消耗。

UUID 的缺點：

1. 不易於儲存：UUID 太長，16 位元組 128 位，通常以 36 長度的字串表示，很多場景不適用。

2. 資訊不安全：基於 MAC 地址生成 UUID 的演算法可能會造成 MAC 地址洩露，這個漏洞曾被用於尋找梅麗莎病毒的製作者位置。

3. ID 作為主鍵時在特定的環境會存在一些問題，比如做 DB 主鍵的場景下，UUID 就非常不適用。MySQL 官方有明確的建議主鍵要儘量越短越好，36 個字元長度的 UUID 不符合要求；UUID 還對 MySQL 索引不利，如果作為資料庫主鍵，在 InnoDB 引擎下，UUID 的無序性可能會引起資料位置頻繁變動，嚴重影響效能。

 

snowflake

 

snowflake 我就不在介紹了，我直接說它的優點：

• 毫秒數在高位，自增序列在低位，整個ID都是趨勢遞增的。

• 不依賴資料庫等第三方系統，以服務的方式部署，穩定性更高，生成ID的效能也是非常高的。

• 可以根據自身業務特性分配bit位，非常靈活。

缺點：

• 強依賴機器時鐘，如果機器上時鐘回撥，會導致發號重複或者服務會處於不可用狀態。

MongDB 的 ObjectID 可以算作是和snowflake類似方法，通過“時間+機器碼+pid+inc”共12個位元組，通過4+3+2+3的方式最終標識成一個24長度的十六進位制字元。

 

美團開源的Leaf

 

支援多種不同模式的生成策略

號段模式：該模式需要建 DB 表, 需要有專門的服務來提供獲取 id 的介面, 存在網路延遲
Snowflake 模式：為了追求更高的效能，需要通過 RPC Server 來部署 Leaf 服務，那僅需要引入 leaf-core 的包，把生成 ID 的 API 封裝到指定的 RPC 框架中即可

缺點，可能就是相對來說比較複雜。

 

sharding-jdbc

 

sharding-jdbc 是一個開源的主鍵生成元件。它的特點是簡單易用，可以指定 workerId 或者不指定, 直接通過 jar 的方式引入即可。看它的名字就知道，它需要 DB 支援。

 

uid-generator

 

uid-generator 是百度開源的一個分散式 ID 生成器。需要建 DB 表, 需要有專門的服務來提供獲取 id 的介面, 存在網路延遲。

原文連結：https://www.xttblog.com/?p=3975

10T技術資源大放送！包括但不限於：C/C++，Linux，Python，Java，PHP，人工智慧，GO等等。在公眾號內回覆對應關鍵字或框架名字，即可免費獲取！！

 你再主動一點點   我們就有故事了