怎么生成全局唯一ID

全局ID生成

目前TDDL(Taobao Distribute Data Layer)提供的id生成是依托数据库来进行的,oracle可以直接使用sequence来完成,mysql需要dba建议一个表专门用于生成id。

为什么需要全局id?

1、在分布式环境中,数据库是可以拆分的,一张表的自增机制只能保证该表唯一,在数据合并到历史库,迁移或者查询,如果出现id冲突,简直就是噩梦。

2、数据库访问时高成本的操作,也要避免每次INSERT都要到id生成器作DB层面的查询。

业界常用的一些UUID方案。

1、UUID

UUID由以下几部分组合:

1)当前日期和时间,UUID的第一部分与时间有关,如果你在生成一个UUID之后,过几秒又生成一个UUID,则第一部分不同,其余相同。

2)时钟序列

3)全局唯一的IEEE机器识别号,如果有网卡,从网卡MAC地址获得,没有网卡以其他方式获得。

优势:API简单、易用

不足:占用空间大、字符串本身无法加工,可读性不强。

2、ID生成表模式

使用id生成表,比较经典的时Flicker的案例,Flicker在解决全局id生成方案里采用了mysql自增长id的机制。先创建单独的数据库,然后创建一个表:

1
2
3
4
5
6
Create table 'Tickerts64'(
'id' bigint(20) unsigned not null auto_increment,
'stub' char(1) not null dafault '',
primary key ('id'),
unique key 'stub'('stub')
)engine=myisam

在应用端做下面两个操作就可以拿到不断增长且不重复的id了。

1
2
replace into  tickers64(stub)values('a');
select last_insert_id();

到上面为止,只是在单台数据库上生成id,从高可用角度考虑,要解决单点故障问题,flicker的方案是启用两台数据库服务器来生成id,通过区分auto_increment的起始值和步长来生成奇偶数id。

优势:简单易用,也有一定的高可用方案

不足:使用了mysql数据库的独特语法Replae INTO.

3、Snowflake

twitter在把存储系统从mysl迁移到Cassandra的过程中由于Cansandra没有顺序id生成机制,于是自己开发了一套全局唯一id生成器snowflake,github地址:https://github.com/twitter/snowflake。根据twitter的业务需求,snowflaker生成64位id。由3部分组成:

  • 41位的时间序列(精确到毫秒,41位长度可以用69年)
  • 10位的机器标识(最多支持部署1024个节点)
  • 12位的计数顺序号(支持每个节点每毫秒产生4096个ID序号)

优点:高性能 ,低延迟;独立的应用,按时间有序

缺点:需要独立的开发和部署

4、集合缓存方案

可以结合ID生成表模式,成批获取id比如1000放到本地缓存,这样client使用时候可进一步提升性能。

优点:高性能,低延迟

缺点:ID不连贯

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×