UUID
全局唯一标识 (Universally unique identifier)
UUID是什么
它是一个由128位二进制组成的标识符,通常以32个十六进制数字表示,例如:550e8400-e29b-41d4-a716-446655440000
。
UUID出现的目的是为了在分布式系统中唯一地标识信息,而不需要集中管理。这使得多个系统或组件可以生成独立的标识符,而不会发生冲突。
UUID常见版本
- UUIDv1:基于时间和节点
- 组成:60位的时间戳、14位的时钟序列和48位的节点(通常是MAC地址)。
- 特点:时间戳和节点信息确保在同一时间生成的UUID不同,但如果系统时间被调整或多个节点使用相同的MAC地址,可能会出现冲突。
- 用途:适用于需要根据时间顺序生成唯一标识符的场景。
- UUIDv2:基于DCE安全
- 组成:与UUIDv1类似,但使用POSIX UIDs为主。
- 特点:包含了POSIX UID/GID信息,主要用于特定的安全应用。
- 用途:较少使用,一般用于特定的DCE(Distributed Computing Environment)应用。
- UUIDv3:基于名字的MD5哈希
- 组成:命名空间和名字的MD5哈希值。
- 特点:相同的命名空间和名字生成相同的UUID,因此对于给定的输入是确定的。
- 用途:适用于需要生成固定UUID的场景,例如基于资源名称生成UUID。
- UUIDv4:基于随机数
- 组成:122位随机数加上版本和变体信息。
- 特点:高度随机,碰撞概率极低。可以独立生成,无需依赖外部信息。
- 用途:广泛应用于需要高唯一性的场景,如会话ID、事务ID等。
- UUIDv5:基于名字的SHA-1哈希
- 组成:命名空间和名字的SHA-1哈希值。
- 特点:与UUIDv3类似,但使用SHA-1代替MD5,提供更好的哈希特性。
- 用途:适用于生成确定性UUID的场景,替代UUIDv3以获得更好的哈希算法。
选择合适的UUID版本取决于具体需求:
- UUIDv1:适用于需要时间排序且能接受暴露部分系统信息的场景。
- UUIDv3和UUIDv5:适用于需要生成确定性UUID的场景。
- UUIDv4:适用于需要高唯一性且不关心生成顺序的场景,常用且最为通用。
windows注册表中的UUID
UUID结构
RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace (rfc-editor.org)
以下是UUIDv1的组成结构图:
1 | Field Name | Bit Length | Hex Digits | Example |
UUIDv1由以下字段组成:
- timestamp (60 bits): 以100纳秒为单位的时间戳,从1582年10月15日起计时。
- low field (32 bits)
- mid field (16 bits)
- hi-and-version field (16 bits)
- clock sequence (14 bits): 时钟序列,用于避免在同一时间戳内生成重复的UUID。
- variant (2 bits): 定义UUID的变体。
- clock-seq-high-and-reserved (6 bits)
- clock-seq-low (8 bits)
- node (48 bits): 通常是设备的MAC地址。
看一下这个UUID的结构1d4a709c-9ac4-11e1-8056-0800200c9a66
1d4a709c
: 时间戳的低位部分(time_low)。9ac4
: 时间戳的中间部分(time_mid)。11e1
: 高位时间戳和版本号(time_hi_and_version),其中第一个”1”表示这是UUID第1版本。80
: 时钟序列高位和变体(clock_seq_hi_and_res),其中”8”表示这是RFC 4122标准的UUID。56
: 时钟序列低位(clock_seq_low)。0800200c9a66
: 节点(node),通常是设备的MAC地址。
通过这个结构,UUIDv1能够保证在全球范围内生成的唯一性,利用时间戳和设备信息来减小碰撞概率。UUID的其他版本(如UUIDv4)具有不同的生成方式和结构,但基本格式保持一致。
总结
UUID在使用时最大的问题就是把它作为索引效果非常差,首先UUID长度是128位,这会增加索引大小。其次,这种ID虽然可以保证它是唯一的,但是不能保证它是自增的,不自增的主键会影响到数据库的各种操作。