全局唯一ID(GUID)生成方案对比

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

背景:在实现大型分布式程序时,通常会有全局唯一ID(也成GUID)生成的需求,用来对每一个对象标识一个代号。本文就列举了博主收集的各种全局唯一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的存储过程,性能较差
全局唯一ID(GUID)生成方案对比

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/tech/linux/41015.html

(0)
上一篇 2021年8月4日 22:54
下一篇 2021年8月4日 22:54

相关推荐

发表回复

登录后才能评论