title: 'UUID生成算法,UUID还是snowflake' toc: true date: 2020-02-09 15:51:08 cover: https://img.paulzzh.com/touhou/random?22 categories: 分布式 tags: [分布式, UUID]
UUID是通用唯一识别码（Universally Unique Identifier）的缩写, 其目的是让分布式系统中的所有元素，都能有唯一的辨识资讯，而不需要透过中央控制端来做辨识资讯的指定。如此一来，就不需考虑数据库建立时的名称重复问题. 目前最广泛应用的 UUID，即是微软的 Microsoft's Globally Unique Identifiers (GUIDs)，而其他重要的应用，则有 Linux ext2/ext3 档案系统、LUKS 加密分割区等
本篇总结了一些UUID生成算法, 以及一些UUID生成算法的实现；
系列文章：
<br/>
<!--more-->UUID是Universally Unique Identifier的缩写，它是在一定的范围内（从特定的名字空间到全球）唯一的机器生成的标识符。UUID具有以下涵义:
为了保证UUID的唯一性，规范定义了包括网卡MAC地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素，以及从这些元素生成UUID的算法。UUID的复杂特性在保证了其唯一性的同时，意味着只能由计算机生成
UUID是不能人工指定的，除非你冒着UUID重复的风险。UUID的复杂性决定了一般人不能直接从一个UUID知道哪个对象和它关联
UUID的生成规范定义的算法主要目的就是要保证其唯一性。但这个唯一性是有限的，只在特定的范围内才能得到保证，这和UUID的类型有关（参见UUID的版本）
UUID是16字节128位长的数字，通常以36字节的字符串表示，示例如下:
3F2504E0-4F89-11D3-9A0C-0305E82C3301
<br/>
<font color="#f00">**其中的字母是16进制表示，大小写无关**</font>
Universally Unique IDentifier(UUID)，有着正儿八经的RFC规范，是一个128bit的数字，也可以表现为32个16进制的字符，中间用”-”分割:
GUID（Globally Unique Identifier）是UUID的别名；但在实际应用中，GUID通常是指微软实现的UUID
<br/>
UUID是指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成的API。按照开放软件基金会(OSF)制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和随机数
UUID由以下几部分的组合：
<font color="#f00">**UUID的唯一缺陷在于生成的结果串会比较长**</font>
<br/>
摘自百度百科: UUID
<br/>
UUID具有多个版本，每个版本的算法不同，应用范围也不同
① Null的UUID
首先是一个特例: Nil UUID(通常我们不会用到它，它是由全为0的数字组成)：00000000-0000-0000-0000-000000000000
② Version-1: 基于时间的UUID
<font color="#f00">**基于时间的UUID通过计算当前时间戳、随机数和机器MAC地址得到**</font>
因为时间戳有满满的60bit，所以可以尽情花，以100纳秒为1，从1582年10月15日算起, 能撑3655年
节点标识也有48bit，一般用MAC地址表达，如果有多块网卡就随便用一块。如果没网卡，就用随机数凑数，或者拿一堆尽量多的其他的信息，比如主机名什么的，拼在一起再hash一把
<br/>
补充:
由于在算法中使用了MAC地址，这个版本的UUID可以保证在全球范围的唯一性, 但与此同时，使用MAC地址会带来安全性问题，这就是这个版本UUID受到批评的地方, 如果应用只是在局域网中使用，也可以使用退化的算法，以IP地址来代替MAC地址 -> Java的UUID往往是这样实现的（当然也考虑了获取MAC的难度）
顺序号这16bit则仅用于避免前面的节点标示改变（如网卡改了），时钟系统出问题（如重启后时钟快了慢了），让它随机一下避免重复
但好像Version-1就没考虑过一台机器上起了两个进程这类的问题，也没考虑相同时间戳的并发问题，所以严格的Version1没人实现，接着往下看各个变种吧
<br/>
Hibernate的CustomVersionOneStrategy.java，解决了之前version-1的两个问题:
<br/>
值得留意就是: 机器进程和进程标识组成的64bit Long几乎不变，只变动另一个Long就够了
MongoDB的ObjectId.java的定义:
<br/>
评价:
MongoDB的每一个字段设计都比Hibernate的更合理一点，比如时间戳是秒级别的, 总长度也降到了12 bytes 96bit，但如果用64bit长的Long来保存有点不上不下的，只能表达成byte数组或16进制字符串
snowflake也是一个派号器，基于Thrift的服务，不过不是用redis简单自增，而是类似UUID version-1
由于只有一个Long 64bit的长度，所以IdWorker紧巴巴的分配成:
<br/>
评价:
因为是派号器，把机器标识和进程标识都省出来了，所以能够只用一个Long表达
另外，这种派号器，client每次只能一个ID，不能批量取，所以额外增加的延时是问题
<br/>
更多snowflake相关内容:
③ Version-2: DCE安全的UUID
DCE（Distributed Computing Environment）安全的UUID和基于时间的UUID算法相同，但会把时间戳的前4位置换为POSIX的UID或GID。这个版本的UUID在实际中较少用到
④ Version-3: 基于名字的UUID（MD5）
基于名字的UUID通过计算名字和名字空间的MD5散列值得到
这个版本的UUID保证了：
⑤ Version-4: 随机UUID
根据随机数，或者伪随机数生成UUID
这种UUID产生重复的概率是可以计算出来的，但随机的东西就像是买彩票：你指望它发财是不可能的
⑥ 基于名字的UUID（SHA1）
和基于名字的UUID算法类似，只是散列值计算使用SHA1（Secure Hash Algorithm 1）算法
<br/>
UUID可以用在一些需要生成全局唯一ID的场景, 如:
而从UUID的不同版本可以看出:
Version-1/2适合应用于分布式计算环境下，具有高度的唯一性；
Version-3/5适合于一定范围内名字唯一，且需要或可能会重复生成UUID的环境下；
<br/>
对于具有名称不可重复的自然特性的对象，最好使用Version-3/5的UUID, 比如系统中的用户:
如果用户的UUID是Version-1的，如果你不小心删除了再重建用户，你会发现人还是那个人，用户已经不是那个用户了(虽然标记为删除状态也是一种解决方案，但会带来实现上的复杂性)
至于Version-4，我个人的建议是最好不用（虽然它是最简单最方便的）
通常我们建议使用UUID来标识对象或持久化数据，但以下情况最好不使用UUID：
<br/>
下面是一些可用的Java UUID生成器：
UUID性能比较: 使用java9的uuid生成方式，让uuid生成速度提升一个档次
<br/>
系列文章：
参考文章: