分布式Unique ID的生成方法

分布式的Unique ID的用途如此广泛,从业务对象Id到日志的TraceId,本文总结了林林总总的各种生成算法。

1. 发号器

我接触的最早的Unique ID,就是Oracle的自增ID。

特点是准连续的自增数字,为什么说是准连续?因为性能考虑,每个Client一次会领20个ID回去慢慢用,用完了再来拿。另一个Client过来,拿的就是另外20个ID了。

新浪微博里,Tim用Redis做相同的事情,Incr一下拿一批ID回去。如果有多个数据中心,那就拿高位的几个bit来区分。

只要舍得在总架构里增加额外Redis带来的复杂度,一个64bit的long就够表达了,而且不可能有重复ID。

2. UUID

2.1 概述

Universally Unique IDentifier(UUID),有着正儿八经的RFC规范,是一个128bit的数字,也可以表现为32个16进制的字符,中间用”-"分割。

- 时间戳+UUID版本号,分三段占16个字符(60bit+4bit),
- Clock Sequence号与保留字段,占4个字符(13bit+3bit),
- 节点标识占12个字符(48bit),

比如:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

实际上,UUID一共有多种算法,能用于TraceId的是:

- version1: 基于时间的算法
- version4: 基于随机数的算法

version 4

先说Version4,这是最暴力的做法,也是JDK里的算法,不管原来各个位的含义了,除了少数几个位必须按规范填,其余全部用随机数表达。

JDK里的实现,用 SecureRandom生成了16个随机的Byte,用2个long来存储。记得加-Djava.security.egd=file:/dev/./urandom,否则会锁住程序等噪音。
详见 JVM上的随机数与熵池策略

version 1

然后是Version1,严格守着原来各个位的规矩:

因为时间戳有满满的60bit,所以可以尽情花,以100纳秒为1,从1582年10月15日算起(能撑3655年,真是位数多给烧的,1582年有意思么)

节点标识也有48bit,一般用MAC地址表达,如果有多块网卡就随便用一块。如果没网卡,就用随机数凑数,或者拿一堆尽量多的其他的信息,比如主机名什么的,拼在一起再hash一把。

顺序号这16bit则仅用于避免前面的节点标示改变(如网卡改了),时钟系统出问题(如重启后时钟快了慢了),让它随机一下避免重复。

但好像Version 1就没考虑过一台机器上起了两个进程这类的问题,也没考虑相同时间戳的并发问题,所以严格的Version1没人实现,接着往下看各个变种吧。

Version1变种 - Hibernate

Hibernate的CustomVersionOneStrategy.java,解决了之前version 1的两个问题

- 时间戳(6bytes, 48bit):毫秒级别的,从1970年算起,能撑8925年....
- 顺序号(2bytes, 16bit, 最大值65535): 没有时间戳过了一秒要归零的事,各搞各的,short溢出到了负数就归0。
- 机器标识(4bytes 32bit): 拿localHost的IP地址,IPV4呢正好4个byte,但如果是IPV6要16个bytes,就只拿前4个byte。
- 进程标识(4bytes 32bit): 用当前时间戳右移8位再取整数应付,不信两条线程会同时启动。

值得留意就是,机器进程和进程标识组成的64bit Long几乎不变,只变动另一个Long就够了。

Version1变种 - MongoDB

MongoDB的ObjectId.java

- 时间戳(4 bytes 32bit): 是秒级别的,从1970年算起,能撑136年。

- 自增序列(3bytes 24bit, 最大值一千六百万): 是一个从随机数开始(机智)的Int不断加一,也没有时间戳过了一秒要归零的事,各搞各的。因为只有3bytes,所以一个4bytes的Int还要截一下后3bytes。

- 机器标识(3bytes 24bit): 将所有网卡的Mac地址拼在一起做个HashCode,同样一个int还要截一下后3bytes。搞不到网卡就用随机数混过去。

- 进程标识(2bytes 16bits):从JMX里搞回来到进程号,搞不到就用进程名的hash或者随机数混过去。

可见,MongoDB的每一个字段设计都比Hibernate的更合理一点,比如时间戳是秒级别的。总长度也降到了12 bytes 96bit,但如果果用64bit长的Long来保存有点不上不下的,只能表达成byte数组或16进制字符串。

另外对Java版的driver在自增序列那里好像有bug。

Twitter的snowflake

snowflake也是一个派号器,基于Thrift的服务,不过不是用redis简单自增,而是类似UUID version1,

只有一个Long 64bit的长度,所以IdWorker紧巴巴的分配成:

- 时间戳(42bit) 自从2012年以来(比那些从1970年算起的会过日子)的毫秒数,能撑139年。
- 自增序列(12bit,最大值4096), 毫秒之内的自增,过了一毫秒会重新置0。
- DataCenter ID (5 bit, 最大值32),配置值。
- Worker ID ( 5 bit, 最大值32),配置值,因为是派号器的id,所以一个数据中心里最多32个派号器就够了,还会在ZK里做下注册。

可见,因为是派号器,把机器标识和进程标识都省出来了,所以能够只用一个Long表达。

但是,这种派号器,client每次只能一个ID,不能批量取,所以额外增加的延时是问题。

可能觉得用原生的Thirft做传输层不够好,snowflake后来又收回去了不对外开源了。

最后问题,能不能不用派号器,又一个Long搞定UUID??

如果当初你的ID一开始类型设为了Long,又不用派号器的话,怎么办?

思路一,压缩其他字段,留足够多的长度来做机器+进程号标识

时间戳是秒级别,1年要24位,两年要25位.....
自增序列,6万QPS要16位,10万要17位...
剩下20-24位,百万分之一到一千六百万分之一的重复率,然后把网卡Mac+进程号拼在一起再hash,取结果32个bit的后面20或24个bit。但假如这个标识字段重复了,后面时间戳和自增序列也很容易重复,不停的重复。

思路二,使用ZK 或 mysql 或 redis来自增管理标识号

如果workder字段的位数留得够多,比如有20位(一百万),那用redis或mysql来自增最简单,每个进程启动时拿一个wokrder id。
如果只留了12位(4096),就要用ZK或etcd,当进程关闭了要回收这个号。

思路三,继续Random

继续拼了,直接拿JDK UUID.randomUUID()的低位long(按UUID规范,高位的long被置了4个默认值的bit,低位只被设置3个bit),或者直接SecureRandom.nextLong(),不浪费了那3个bit。

参考资料:

一乐那篇《业务系统需要什么样的ID生成器》,其中 唯一性,时间相关,粗略有序,可反解,可制造 这个提法很好,说白了就是让大家尽量用UUID version1风格。

分布式Unique ID的生成方法的更多相关文章

  1. [转帖]分布式Unique ID的生成方法一览

    分布式Unique ID的生成方法一览 http://www.importnew.com/22211.html 分布式的Unique ID的用途如此广泛,从业务对象Id到日志的TraceId,本文总结 ...

  2. 分布式系统中Unique ID 的生成方法

    http://darktea.github.io/notes/2013/12/08/Unique-ID 本文主要介绍在一个分布式系统中, 怎么样生成全局唯一的 ID 一, 问题描述 在分布式系统存在多 ...

  3. 分布式系统中 Unique ID 的生成方法

    http://darktea.github.io/notes/2013/12/08/Unique-ID Snowflake 生成的 unique ID 的组成 (由高位到低位): 41 bits: T ...

  4. 分表分库之二:唯一ID的生成方法

    一.为什么要全局唯一? 我们在对数据库集群作扩容时,为了保证负载的平衡,需要在不同的Shard之间进行数据的移动, 如果主键不唯一,我们就没办法这样随意的移动数据.起初,我们考虑采用组合主键来解决这个 ...

  5. 分布式系统中唯一 ID 的生成方法

    在分布式系统存在多个 Shard 的场景中, 同时在各个 Shard 插入数据时, 怎么给这些数据生成全局的 unique ID? 在单机系统中 (例如一个 MySQL 实例), unique ID ...

  6. 分布式系统ID的生成方法之UUID、数据库、算法、Redis、Leaf方案

    一般单机或者单数据库的项目可能规模比较小,适应的场景也比较有限,平台的访问量和业务量都较小,业务ID的生成方式比较原始但是够用,它并没有给这样的系统带来问题和瓶颈,所以这种情况下我们并没有对此给予太多 ...

  7. 分布式唯一ID的生成方案

    分布式ID的特性 全局唯一 不能出现重复的ID,这是最基本的要求. 递增 有利于关系数据库索引性能. 高可用 既然是服务于分布式系统,为多个服务提供ID服务,访问压力一定很大,所以需要保证高可用. 信 ...

  8. Twitter的分布式系统中ID生成方法——Snowflake

    Twitter-Snowflake算法产生的背景相当简单,为了满足Twitter每秒上万条消息的请求,每条消息都必须分配一条唯一的id,这些id还需要一些大致的顺序(方便客户端排序),并且在分布式系统 ...

  9. 讲分布式唯一id,这篇文章很实在

    分布式唯一ID介绍 分布式系统全局唯一的 id 是所有系统都会遇到的场景,往往会被用在搜索,存储方面,用于作为唯一的标识或者排序,比如全局唯一的订单号,优惠券的券码等,如果出现两个相同的订单号,对于用 ...

随机推荐

  1. uva 11400 Problem F Lighting System Design

    紫皮书题: 题意:让你设计照明系统,给你n种灯泡,每种灯泡有所需电压,电源,每个灯泡的费用,以及每个灯泡所需的数量.每种灯泡所需的电源都是不同的,其中电压大的灯泡可以替换电压小的灯泡,要求求出最小费用 ...

  2. 【数据库摘要】12_Sql_存储过程

    SQL 存储过程 存储过程创建语法: create or replace procedure 存储过程名(param1 in type,param2 out type) as 变量1 类型(值范围); ...

  3. 一个解析RTSP 的URL函数

    写了一个解析URL的函数,可以提取URL中的IP 和 port. 如:url = "rtsp://192.168.1.43:2554/realmp3.mp3"; url = &qu ...

  4. TFS2010安装与管理

    整了几天TFS,把相关的一些配置与安装的要点简单记下,希望对大家有用.本篇主要是安装与配置上的内容,下一篇会介绍如何使用以及使用方面的相关心得体会. 本篇内容简要: 1.   安装部署 1.1.  流 ...

  5. xvfb 初步探究

    有时候我们不关注程序是否有界面(比如自动化测试),只要程序在运行就可以了 很感谢 xvfb 这个工具给我们提供了相关的功能 比如在没有 X server 的机器上运行 gedit, 可以用下面的命令 ...

  6. SRM 624 Building Heights DivI 解读

    几乎相同的一标题.欲了解更多请参阅:http://community.topcoder.com/stat?c=problem_statement&pm=13211&rd=15857 思 ...

  7. Suse 创建NFS共享目录

    Suse 创建NFS共享目录 服务端的配置: 1.编辑nfs服务的配置文件 /software/suse11 *(rw,sync,no_root_squash,no_all_squash) 凝视: / ...

  8. ubuntu 64位下安装wps

    首先,去官网下载wps.地址:http://community.wps.cn/download/ 然后切换到下载文件夹.运行例如以下命令: $ sudo apt-get install ia32-li ...

  9. Mono和Jexus并且部署ASP.NET MVC3、4、5和WebApi

    Linux(CentOS 6.7)下配置Mono和Jexus并且部署ASP.NET MVC3.4.5和WebApi(跨平台) 1.开篇说明 a. 首先我在写这篇博客之前,已经在自己本地配置了mono和 ...

  10. JAVA进阶----主线程等待子线程各种方案比较(转)

    创建线程以及管理线程池基本理解 参考原文链接:http://www.oschina.net/question/12_11255?sort=time 一.创建一个简单的java线程 在 Java 语言中 ...