分布式ID生成方式

生成方式:

1.UUID
2.数据库自增ID
3.数据库多主模式
4.号段模式
5.Redis
6.雪花算法(SnowFlake)
7.滴滴出品(TinyID)
8.百度 (Uidgenerator)
9.美团(Leaf)

文章目录

  • ​​1.UUID​​
  • ​​2.数据库自增Id​​
  • ​​3.基于数据库集群模式​​
  • ​​4.基于数据库的号段模式​​
  • ​​5.Redis​​
  • ​​6.Snowflake​​
  • ​​7.百度(uid-generator)​​
  • ​​8.Leaf​​
  • ​​9.TinyId​​

1.UUID

public static void main(String[] args) { 
String uuid = UUID.randomUUID().toString().replaceAll("-","");
System.out.println(uuid);
}

UUID的生成简单到只有一行代码,输出结果 c2b8c2b9e46c47e3b30dca3b0d447718,但UUID却并不适用于实际的业务需求。像用作订单号UUID这样的字符串没有丝毫的意义,看不出和订单相关的有用信息;而对于数据库来说用作业务主键ID,它不仅是太长还是字符串,存储性能差查询也很耗时,所以不推荐用作分布式ID。

简单具有唯一性但是无序,无业务含义,长度过长,16字节,如果是Mysql存储的话会影响性能

2.数据库自增Id

基于数据库的auto_increment自增ID完全可以充当分布式ID,具体实现:需要一个单独的MySQL实例用来生成ID,建表结构如下:

CREATE DATABASE `SEQ_ID`;
CREATE TABLE SEQID.SEQUENCE_ID (
id bigint(20) unsigned NOT NULL auto_increment,
value char(10) NOT NULL default '',
PRIMARY KEY (id),
) ENGINE=MyISAM;
insert into SEQUENCE_ID(value) VALUES ('values');

当我们需要一个ID的时候,向表中插入一条记录返回主键ID,但这种方式有一个比较致命的缺点,访问量激增时MySQL本身就是系统的瓶颈,用它来实现分布式服务风险比较大,不推荐!

简单,数据库查询快,但是无法解决高并发的情况

3.基于数据库集群模式

前边说了单点数据库方式不可取,那对上边的方式做一些高可用优化,换成主从模式集群。害怕一个主节点挂掉没法用,那就做双主模式集群,也就是两个Mysql实例都能单独的生产自增ID。

重复Id的解决方案:

Mysql_1

set @@auto_increment_offset = 1;     -- 起始值
set @@auto_increment_increment = 2; -- 步长

Mysql_2

set @@auto_increment_offset = 2;     -- 起始值
set @@auto_increment_increment = 2; -- 步长

缺点是不好扩展,无法扩容,无法解决高并发的场景

4.基于数据库的号段模式

号段模式可以理解为从数据库批量的获取自增ID,每次从数据库取出一个号段范围,例如 (1,1000] 代表1000个ID,具体的业务服务将本号段,生成1~1000的自增ID并加载到内存。表结构如下:

CREATE TABLE id_generator (
id int(10) NOT NULL,
max_id bigint(20) NOT NULL COMMENT '当前最大id',
step int(20) NOT NULL COMMENT '号段的布长',
biz_type int(20) NOT NULL COMMENT '业务类型',
version int(20) NOT NULL COMMENT '版本号',
PRIMARY KEY (`id`)
)

biz_type :代表不同业务类型

max_id :当前最大的可用id

step :代表号段的长度

version :是一个乐观锁,每次都更新version,保证并发时数据的正确性

等这批号段ID用完,再次向数据库申请新号段,对max_id字段做一次update操作,update max_id= max_id + step,update成功则说明新号段获取成功,新的号段范围是(max_id ,max_id +step]。

由于多业务端可能同时操作,所以采用版本号version乐观锁方式更新,这种分布式ID生成方式不强依赖于数据库,不会频繁的访问数据库,对数据库的压力小很多。

5.Redis

Redis是基于incr命令的自增

127.0.0.1:6379> set seq_id 1     // 初始化自增ID为1
OK
127.0.0.1:6379> incr seq_id // 增加1,并返回递增后的数值
(integer) 2

redis实现需要注意一点,要考虑到redis持久化的问题。redis有两种持久化方式RDB和AOF。

  • RDB会定时打一个快照进行持久化,假如连续自增但redis没及时持久化,而这会Redis挂掉了,重启Redis后会出现ID重复的情况。
  • AOF会对每条写命令进行持久化,即使Redis挂掉了也不会出现ID重复的情况,但由于incr命令的特殊性,会导致Redis重启恢复的数据时间过长。

6.Snowflake

分布式ID生成方式
​雪花算法原理

7.百度(uid-generator)

uid-generator是基于Snowflake算法实现的,与原始的snowflake算法不同在于,uid-generator支持自定义时间戳、工作机器ID和 序列号 等各部分的位数,而且uid-generator中采用用户自定义workId的生成策略。

uid-generator需要与数据库配合使用,需要新增一个WORKER_NODE表。当应用启动时会向数据库表中去插入一条数据,插入成功后返回的自增ID就是该机器的workId数据由host,port组成。

uid-generator组成:
workId,占用了22个bit位,时间占用了28个bit位,序列化占用了13个bit位,需要注意的是,和原始的snowflake不太一样,时间的单位是秒,而不是毫秒,workId也不一样,而且同一应用每次重启就会消费一个workId。

8.Leaf

Leaf同时支持号段模式和snowflake算法模式,可以切换使用。

9.TinyId

Tinyid是基于号段模式原理实现的与Leaf如出一辙,每个服务获取一个号段(1000,2000]、(2000,3000]、(3000,4000]

分布式ID生成方式
Tinyid提供httptinyid-client两种方式接入