全域性唯一ID（GUID）生成方案對比

盧鈞軼發表於2015-04-12
GUI

本文彙總了各大公司的全域性唯一ID生成方案，並做了一個簡單的優劣比較

背景：在實現大型分散式程式時，通常會有全域性唯一ID（也成GUID）生成的需求，用來對每一個物件標識一個代號。本文就列舉了博主收集的各種全域性唯一ID生成的方案，做一個簡單的類比和備忘。

GUID的基本需求

一般對於唯一ID生成的要求主要這麼幾點：

  • 毫秒級的快速響應
  • 可用性強
  • prefix有連續性方便DB順序儲存
  • 體積小，8位元組為佳

業界成熟方案列舉

目前看到過的唯一ID生成方法主要有以下幾種：

各個方案優劣的對比

四種方案各有優劣，下面簡要描述以下：

  • UUID：
    • 優：java自帶，好用。
    • 劣：佔用空間大
  • Snowflake： timestamp + work number + seq number
    • 優：可用性強，速度快
    • 劣：需要引入zookeeper 和獨立的snowflake專用伺服器
  • Flikr：基於int/bigint的自增
    • 優：開發成本低
    • 劣：如果需要高效能，需要專門一套MySQL叢集只用於生成自增ID。可用性也不強
  • Instagram：41b ts + 13b shard id + 10b increment seq
    • 優： 開發成本低
    • 劣： 基於postgreSQL的儲存過程，通用性差
  • UUID變種：timestamp + machine number + random （具體見：變種介紹）
    • 優： 開發成本低
    • 劣： 基於MySQL的儲存過程，效能較差

相關文章