分布式系统的唯一id生成算法

背景:如果分库分表场景下,id不唯一,就不能通过主键索引来查询了。

1、独立数据库自增id

这个方案就是说你的系统每次要生成一个 id,都是往一个独立库的一个独立表里插入一条没什 么业务含义的数据,然后获取一个数据库自增的一个 id。拿到这个 id 之后再往对应的分库分表 里去写入。 假如说你有一个 auto_id 库里有一个叫做 auto_id的 表,有一个 id 是自增的。 那么你每次要获取一个全局唯一 id,直接往这个表里插入一条记录,获取一个全局唯一 id 即 可,然后这个全局唯一 id 就可以插入订单的分库分表中。 这个方案的好处就是方便简单,谁都会用。缺点就是单库生成自增 id,要是搞并发的话,就会 有瓶颈的,因为 auto_id 库要是承载个每秒几万并发,肯定是不现实的了。

2、UUID

用UUID 生成一个全局唯一的 id。
好处就是每个系统本地生成,不要基于数据库来了
不好之处就是,uuid 太长了(32位),作为主键性能太差了,不适合用于主键。 如果你是要随机生成个什么文件名了,编号之类的,你可以用 uuid,但是作为主键是不能用 uuid 的。

3、获取系统当前时间

这个方案的意思就是获取当前时间作为全局唯一的 id。 但是问题是,并发很高的时候,比如1秒并发几千,会有重复的情况,这个是肯定不合适的。 一般如果使用这个方案,是将当前时间跟很多其他的业务字段拼接起来,作为一个 id,如果业务 上可以接受,那么也是可以的。 可以将别的业务字段值跟当前时间拼接起来,组成一个全局唯一的编号,比如说订单编号: 时间戳 + 用户 id + 业务含义编码;或者 时间戳+6个随机数(26个英文字母+数字)
同时,表索引可以添加唯一索引。

4、snowflake 算法

snowflake 算法,是 twitter 开源的分布式 id 生成算法
其核心思想就是:使用一个 64 bit 的 long 型的数字作为全局唯一 id,这 64 个 bit 中,其中 1 个 bit 是不用的,然后用其中的 41 bit 作为毫秒数,用10 bit 作为工作机器 id,12 bit 作为序列 号。

image.png

第一部分,是 1 个 bit:0,这个是无意义的(因为二进制里第一个 bit 为如果是 1,那么都是负数,但是我们生成的 id 都是正数,所 以第一个 bit 统一都是 0)
第二个部分是 41 个 bit:表示的是时间戳,单位是毫秒(41 bit 可以表示的数字多达 2^41 - 1,也就是可以标识 2 ^ 41 - 1 个毫秒值,换算成年就 是表示 69 年的时间。)
第三个部分是 5 个 bit:表示的是机房 id,10001 (最多代表2 ^ 5个机房(32 个机房))
第四个部分是 5 个 bit:表示的是机器 id,1 1001 (每个机房⾥可以代表2 ^ 5个机器(32台机器))
第五个部分是 12 个 bit:表示的序号,就是某个机房某台机器上这一毫秒内同时生成的 id 的序号,0000 00000000(12 bit可以代表的最大正整数是2 ^ 12 - 1 = 4096,也就是说可以用这个12bit代表的数字 来区分同1个毫秒内的4096个不同的id)

简单来说,你的某个服务假设要生成1个全局唯一id,那么就可以发送1个请求给部署了 snowflake算法的系统,由这个snowflake算法系统来生成唯一id。

snowflake算法系统接收到这个请求之后,首先就会用二进制位运算的方式生成1个64 bit 的long型id,64个bit中的第1个bit是无意义的。 接着41个bit,就可以用当前时间戳(单位到毫秒),然后接着5个bit设置上这个机房id,还有5 个bit设置上机器id。 最后再判断一下,当前这台机房的这台机器上这1毫秒内,这是第几个请求,给这次生成id的 请求累加一个序号,作为最后的12个bit。 最终一个64个bit的id就出来了,类似于上图中那样。
这个算法可以保证说,一个机房的一台机器上,在同一毫秒内,生成了一个唯一的 id。可能一 个毫秒内会生成多个 id,但是有最后 12 个 bit 的序号来区分开来。总之就是用一个 64bit 的数字中各个 bit 位来设置不同的标志位,区分每一个 id。

image.png

算法实现如下

public class IdWorker { 
private long workerId; // 这个就是代表了机器id 
private long datacenterId; // 这个就是代表了机房id 
private long sequence; // 这个就是代表了1毫秒内生成的多个id的最新序号 
public IdWorker(long workerId, long datacenterId, long sequence) { 

// 要求就是你传递进来的机房id和机器id不能超过32,不能小于于0 
if (workerId > maxWorkerId || workerId < 0) { 
  throw new IllegalArgumentException( String.format("worker Id can't be greater than %d or less t "))
}

if (datacenterId > maxDatacenterId || datacenterId < 0) { 
throw new IllegalArgumentException( String.format("datacenter Id can't be greater than %d or le "))
}

this.workerId = workerId; 
this.datacenterId = datacenterId; 
this.sequence = sequence; 
}

private long twepoch = 1288834974657L; 
private long workerIdBits = 5L; 
private long datacenterIdBits = 5L;

// 这个是二进制运算,就是5 bit最多只能有31个数字,也就是说机器id最多只能是32以内 
private long maxWorkerId = -1L ^ (-1L << workerIdBits); 
// 这个是一个意思,就是5 bit最多只能有31个数字,机房id最多只能是32以内 
private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits); 
private long sequenceBits = 12L; 
private long workerIdShift = sequenceBits; 
private long datacenterIdShift = sequenceBits + workerIdBits; 
private long timestampLeftShift = sequenceBits + workerIdBits + datacen 
private long sequenceMask = -1L ^ (-1L << sequenceBits); 
private long lastTimestamp = -1L; 
public long getWorkerId(){ 
return workerId; 
}
public long getDatacenterId() { 
return datacenterId; 
}
public long getTimestamp() { 
return System.currentTimeMillis(); 
}

// 这个是核心算法,通过调调nextId()方法,让当前这台机器上的snowflake算法程序生成1一个id
 public synchronized long nextId() { 
// 获取当前时间戳,单位是毫秒
 long timestamp = timeGen();
 if (timestamp < lastTimestamp) {
 System.err.printf( "clock is moving backwards. Rejecting requests until %d.", throw new RuntimeException( String.format("Clock moved backwards. Refusing to generate lastTimestamp - timestamp))"));
 }

// 假设在同1个毫秒内又发送了一个请求生成1个id 
// 这个时候就得把seqence序号给递增1,最多就是4096 
if (lastTimestamp == timestamp) {
// 这个意思是说1个毫秒内最多只能有4096个数字,无论你传递多少进来, 
//这个位运算保证始终就是在4096这个范围内,避免传递的sequence超过了4096
sequence = (sequence + 1) & sequenceMask;
 if (sequence == 0) {
 timestamp = tilNextMillis(lastTimestamp);
 } 
} else {
 sequence = 0;
 }
// 记录最近1次生成id的时间戳,单位是毫秒
 lastTimestamp = timestamp;
 // 最核心的二进制位运算操作,生成1个64bit的id 
// 先将当前时间戳左移,放到41 bit那;将机房id左移放到5 bit那;将机器id左移 
// 最后拼接起来成一个64 bit的二进制数字,转换成10进制就是个long型 
return ((timestamp - twepoch) << timestampLeftShift) | (datacenterId << datacenterIdShift) | (workerId << workerIdShift) | sequence; 
}
private long tilNextMillis(long lastTimestamp) {
 long timestamp = timeGen();
 while (timestamp <= lastTimestamp) {
 timestamp = timeGen();
 }return timestamp;
 }
private long timeGen(){
 return System.currentTimeMillis();
 }
//---------------测试--------------- 
public static void main(String[] args) {
 IdWorker worker = new IdWorker(1,1,1);
 for (int i = 0; i < 30; i++) {
System.out.println(worker.nextId()); 
      }
   }
}

在实际的开发中,这个 snowflake 算法可以做小点点改进。 我们在生成唯一 id 的时候,肯定都需要指定一个表名,比如说订单表 的唯一 id。 所以上面那 64 个 bit 中,代表机房的那 5 个 bit,可以使用业务表名称来替代,比如 00001 代表的是订单表。 因为其实很多时候,机房并没有那么多,所以那 5 个 bit 做做机房 id 意义不是太大。 这样就可以做到,snowflake 算法系统的每1台机器,对一个业务表,在某1毫秒内,可生成
1个唯1的 id,1毫秒内生成很多 id,用最后 12 个 bit 来区分序号对待。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,980评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,178评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,868评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,498评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,492评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,521评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,910评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,569评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,793评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,559评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,639评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,342评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,931评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,904评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,144评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,833评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,350评论 2 342

推荐阅读更多精彩内容