Chinaunix首页 | 论坛 | 博客
  • 博客访问: 785258
  • 博文数量: 179
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1536
  • 用 户 组: 普通用户
  • 注册时间: 2015-01-27 11:05
个人简介

MySQL工程师 QQ:1815357042

文章分类

全部博文(179)

文章存档

2015年(179)

分类: Mysql/postgreSQL

2015-04-12 10:00:15

转载自:

本文汇总了各大公司的全局唯一ID生成方案,并做了一个简单的优劣比较

背景:在实现大型分布式程序时,通常会有全局唯一ID(也成GUID)生成的需求,用来对每一个对象标识一个代号。本文就列举了博主收集的各种全局唯一ID生成的方案,做一个简单的类比和备忘。

GUID的基本需求

一般对于唯一ID生成的要求主要这么几点:

  • 毫秒级的快速响应
  • 可用性强
  • prefix有连续性方便DB顺序存储
  • 体积小,8字节为佳

业界成熟方案列举

目前看到过的唯一ID生成方法主要有以下几种:

  •  16字节
  • Twitter的 8字节
  •  4/8字节
  •  8字节
  •  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的存储过程,性能较差
阅读(3880) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~