首選，不管是不是分布式系統，都有 id 唯一的使用場景。而在分布式場景下，對 id 的唯一性要求更嚴格！
常見的，我們上**買東西的訂單 id，就是一種分布式 id。**，前期的訂單 id 好像是 14 位，現在好像已經是 16 位，或者 18 位了吧。
以我們公司的訂單 id 為例，它有這幾個特點。
id 全域性唯一，不會重複
id 的增長支援分布式使用
id 要方便好記，並且通過 id 能大概看出是什麼時間建立的訂單
訂單 id 最好還能追蹤到銷售員，或下單使用者的 id 等
增長的訂單 id 還不能讓競爭對手發現你每天的業務量
所以，設計乙個好的分布式 id 生成器並不是那麼容易的。於是網上也有很多大公司開源這類分布式 id 生成器。我今天就抽個時間，扯一扯它們之間的不同點吧。
說到，分布式 id，我們首選想到的可能就是 uuid 了。
uuid (universally unique identifier) 的標準型式包含 32 個 16 進製數字，以連字型大小分為五段，形式為 8-4-4-4-12 的 36 個字元，示例：550e8400-e29b-41d4-a716-446655440000，到目前為止業界一共有 5 種方式生成 uuid。
uuid 的優點：效能非常高：本地生成，沒有網路消耗。
uuid 的缺點：
不易於儲存：uuid 太長，16 位元組 128 位，通常以 36 長度的字串表示，很多場景不適用。
id 作為主鍵時在特定的環境會存在一些問題，比如做 db 主鍵的場景下，uuid 就非常不適用。mysql 官方有明確的建議主鍵要盡量越短越好，36 個字元長度的 uuid 不符合要求；uuid 還對 mysql 索引不利，如果作為資料庫主鍵，在 innodb 引擎下，uuid 的無序性可能會引起資料位置頻繁變動，嚴重影響效能。
snowflake 我就不在介紹了，我直接說它的優點：
缺點：mongdb 的 objectid 可以算作是和snowflake類似方法，通過「時間+機器碼+pid+inc」共12個位元組，通過4+3+2+3的方式最終標識成乙個24長度的十六進製制字元。
支援多種不同模式的生成策略
號段模式：該模式需要建 db 表, 需要有專門的服務來提供獲取 id 的介面, 存在網路延遲
snowflake 模式：為了追求更高的效能，需要通過 rpc server 來部署 leaf 服務，那僅需要引入 leaf-core 的包，把生成 id 的 api 封裝到指定的 rpc 框架中即可
缺點，可能就是相對來說比較複雜。
sharding-jdbc 是乙個開源的主鍵生成元件。它的特點是簡單易用，可以指定 workerid 或者不指定, 直接通過 jar 的方式引入即可。看它的名字就知道，它需要 db 支援。
分布式ID生成器
一 需求緣起 幾乎所有的業務系統，都有生成乙個唯一記錄標識的需求，例如 這個記錄標識往往就是資料庫中的主鍵，資料庫上會建立聚集索引 cluster index 即在物理儲存上以這個字段排序。這個記錄標識上的查詢，往往又有分頁或者排序的業務需求，例如 所以往往要有乙個time欄位，並且在time欄位上...
分布式 ID 生成器
乙個唯一 id 在乙個分布式系統中是非常重要的乙個業務屬性，其中包括一些如訂單 id，訊息 id 會話 id，他們都有一些共有的特性 全域性唯一很好理解，目的就是唯一標識某個次請求，某個業務。通常有以下幾種方案 可以利用mysql中的自增屬性auto increment來生成全域性唯一 id，也能保...
自學 分布式ID生成器
最近在做乙個專案，遇到了乙個小問題 針對資料庫的主鍵自增這塊怎麼解決，前提是採用分片部署。如果還是用我們之前的方式主鍵自增，會造成乙個表中id的重複。舉例說明 比如有乙個商品表，將這個商品表部署在3臺伺服器上 server1 server2 server3。如果是以前的主鍵自增 server1中會從...