扯扯ID

🙂🙂🙂關注微信公衆號：【芋艿的後端小屋】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 全部源碼分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文註釋源碼 GitHub 地址
3. 您對於源碼的疑問每條留言都將獲得認真回覆。甚至不知道如何讀源碼也能夠請教噢。
4. 新的源碼解析文章實時收到通知。每週更新一篇左右。

---

• 1. 數據庫自增
• 2. 類UUID算法
• 3. SnowFlake
  • 3.1 Twitter-Snowflake
  • 3.2 Instagram SnowFlake
  • 3.3 Simpleflake
  • 3.4 Boundary flake
  • 3.5 本身的想法
• 4. 參考文章

---

在平常開發中，數據庫的id是不可少的。在各個場景下會有不一樣的選擇，本文對互聯網上常見的ID算法進行概括，但願對工程師們有一點點幫助。

1. 數據庫自增

1. MySQL、Oracle、PGSQL等關係數據庫的id主鍵自增
2. Redis、Memcached等K/V數據庫的incr操做自增
   • 須要考慮持久化的問題
3. MongoDB本身維護一個id自增集合
   • MongoDB的Update操做支持incr操做，所以能夠這麼作。
   • 該方式適用於支持該操做的其餘數據庫。

2. 類UUID算法

1. UUID
2. MongoDB的ObjectId

3. SnowFlake

3.1 Twitter-Snowflake

Twitter-Snowflake算法產生的背景至關簡單，爲了知足Twitter每秒上萬條消息的請求，每條消息都必須分配一條惟一的id，這些id還須要一些大體的順序（方便客戶端排序），而且在分佈式系統中不一樣機器產生的id必須不一樣。

64bits從左往右依次是

• 1bit 保留
• 41bits 時間戳
  • 支持69.7年須要的id。2 ^41 /365/24/60/60/1000=69.7
• 10bits work-id
  • 支持1024個work
• 12bits sequence-id
  • 支持每work每毫秒4096個id
  • 支持每work每秒4096000個id
  • 若當前毫秒超過4096，則sleep1毫秒，獲取下一毫秒的自增

snowflake的意義，不單單在於提供瞭解決方式，更多的是一種基於Long長度實現具備時間相關性的id自增序列。所以，不少公司基於它進行二次改造適應本身的場景

3.2 Instagram SnowFlake

去中性化，基於PGSQL實現

64bits從左至右依次是

• 41bits 時間戳
• 13bits logic-shard-id
• 10bits sequence-id

實現方式

• 根據share-key獲取對應的PGSQL實例-庫
• id使用PGSQL的存儲過程
• 13bits = share-key對應值%logic-share-id
• 10bits = 該Table的auto_increment_id%(2 ^10)

好處

• 去中性化
• 根據id能夠得到對應PGSQL實例-庫

3.3 Simpleflake

64bits

• 去中性化
• 將work-id的12bits給sequence-id。徹底隨機，每毫秒有1/(2^22 )出現衝突的狀況。數據量大時須要注意。
• 將來能夠平滑遷移到Twitter SnowFlake

3.4 Boundary flake

去中性化，基於erlang實現
128bits從左到右依次是

• 64bits 時間戳
  • 和毫秒時間戳等長
• 48bits work-id
  • 和mac地址等長，使用時要避免相同mac多個進程
• 14bits sequence-id

3.5 本身的想法

參考Instagram SnowFlake的作法

去中心化，基於redis實現
64bits從左到右依次是

• 1bit 保留
• 41bits 時間戳
• 12bits 基於logic-shard-id
• 10bits 基於時間戳+logic-shard-id在redis裏自增

4. 參考文章

1. 互聯網分佈式id生成方法|msup微課乾貨
2. 服務化框架－分佈式Unique ID的生成方法一覽
3. 分佈式系統中 Unique ID 的生成方法