全域性唯一ID生成方案對比 • cenalulu's Tech Blog
阿新 • • 發佈:2018-12-23
彙總了各大公司的全域性唯一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的儲存過程,效能較差