全局唯一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的存储过程，性能较差 原文发布时间：2015-04-12 本文来自云栖合作伙伴“linux中国” 相关资源：敏捷开发V1.0.pptx