全局唯一ID生成方案对比_MySQL, Oracle及数据库讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MySQL, Oracle及数据库讨论区 »
总帖数
2
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 2523 | 回复: 1   主题: 全局唯一ID生成方案对比        下一篇 
shellyC1314
注册用户
等级:少校
经验:1334
发帖:75
精华:0
注册:2015-7-14
状态:离线
发送短消息息给shellyC1314 加好友    发送短消息息给shellyC1314 发消息
发表于: IP:您无权察看 2015-9-1 10:13:28 | [全部帖] [楼主帖] 楼主

汇总了各大公司的全局唯一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的存储过程,性能较差






赞(0)    操作        顶端 
koei123
注册用户
等级:大校
经验:4196
发帖:16
精华:0
注册:2011-7-21
状态:离线
发送短消息息给koei123 加好友    发送短消息息给koei123 发消息
发表于: IP:您无权察看 2015-9-1 19:17:52 | [全部帖] [楼主帖] 2  楼

GUID这个东西其实很需要



赞(0)    操作        顶端 
总帖数
2
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论