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的存储过程，性能较差