全局唯一ID（GUID）生成方案对比
本文汇总了各大公司的全局唯一ID生成方案，并做了一个简单的优劣比较
背景：在实现大型分布式程序时，通常会有全局唯一ID（也成GUID）生成的需求，用来对每一个对象标识一个代号。本文就列举了博主收集的各种全局唯一ID生成的方案，做一个简单的类比和备忘。
GUID的基本需求
一般对于唯一ID生成的要求主要这么几点：
- 毫秒级的快速响应
- 可用性强
- prefix有连续性方便DB顺序存储
- 体积小，8字节为佳
业界成熟方案列举
目前看到过的唯一ID生成方法主要有以下几种：
- UUID 16字节
- Twitter的Snowflake 8字节
- Flikr的数据库自增 4/8字节
- Instagram的存储过程 8字节
- 基于MySQL UUID的变种 16字节
各个方案优劣的对比
四种方案各有优劣，下面简要描述以下：
- 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的存储过程，性能较差
 );){kind=link}