數據庫 ID

推薦閱讀：

• 漫畫：什麼是SnowFlake算法

一、自增與UUID

• 自增： ID 生成對數據庫依賴嚴重，而且一旦數據庫宕機，服務將變得不可用
• UUID： 生成的 ID 無序，由於數據庫採用 B+ 樹，因此入庫性能差

二、Snowflake

1. Twitter-Snowflake

• 1bit 保留
• 41bits 時間戳： 支持69.7年需要的 id
• 10bits work-id： 支持1024個work
• 12bits sequence-id： 支持每work每毫秒4096個id

  若當前毫秒超過4096，則sleep 1毫秒，獲取下一毫秒的自增

代碼推薦閱讀： Twitter-Snowflake，64位自增ID算法詳解

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. Simpleflake

64bits

• 去中性化
• 將work-id的12bits給sequence-id。完全隨機，每毫秒有1/(2^22 )出現衝突的情況。數據量大時需要注意。
• 未來可以平滑遷移到Twitter SnowFlake

4. Boundary flake

去中性化，基於 erlang 實現

128bits從左到右依次是

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