A 通用唯一标识符 (UUID) 是计算机系统中用于唯一标识信息的 128 位标签。 UUID 被设计为在空间和时间上都是唯一的,允许它们在没有中央权威的情况下独立生成,从而最大限度地减少重复的风险。
UUID 有多种用途,包括:
- 识别数据库中的记录。
- 标记分布式系统中的对象。
- 在唯一性至关重要的应用程序中充当主键。
现实世界的用例
-
数据库:关系数据库中使用UUID作为主键,保证记录的唯一标识。
-
微服务:通过为请求和资源提供唯一标识符来促进服务通信。
-
物联网设备:唯一识别网络中的设备,确保可以聚合多个来源的数据而不会发生冲突。
使用UUID的优点和缺点
优点:
-
全球唯一性:UUID 极不可能发生冲突,这使得它们适合多个节点独立生成标识符的分布式系统。
-
不需要中央权威:它们可以在没有协调的情况下生成,这简化了分布式环境中的操作。
-
可扩展性:它们在需要跨多个服务器或服务进行扩展的系统中运行良好。
缺点:
-
存储大小:与传统整数 ID(通常为 32 位)相比,UUID 消耗更多空间(128 位),这可能导致存储成本增加。
-
性能问题:由于 UUID 的随机性和大小,索引 UUID 会降低数据库性能,导致查询时间比顺序 ID 慢。
-
用户不友好:UUID 在用户界面中呈现时不容易记住或用户友好。
标准
UUID 的标准表示形式由 32 个十六进制字符组成,分为五组,用连字符分隔,遵循格式 8-4-4-4-12,总共 36 个字符(32 个字母数字加 4 个连字符) .
UUID格式可以可视化如下:
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
在哪里:
-
M表示UUID版本。
-
N 表示变体,这有助于解释 UUID 的布局。
UUID 的组成部分
-
TimeLow:4个字节(8个十六进制字符)表示时间戳的低字段。
-
TimeMid:2个字节(4个十六进制字符)表示时间戳的中间字段。
-
TimeHighAndVersion:2 个字节(4 个十六进制字符),包括版本号和时间戳的高字段。
-
ClockSequence:2 个字节(4 个十六进制字符),用于帮助避免冲突,特别是在快速连续生成多个 UUID 或调整系统时钟时。
-
节点:6个字节(12个十六进制字符),通常表示生成节点的MAC地址。
UUID 的类型
版本 1:基于时间的 UUID,使用当前时间戳和生成节点的 MAC 地址的组合。此版本确保跨空间和时间的唯一性。
版本 2:与版本 1 类似,但包含本地域标识符;然而,由于其局限性,它不太常用。
版本 3:使用命名空间标识符和名称的 MD5 哈希生成的基于名称的 UUID。
版本 4:随机生成的 UUID,提供高度随机性和唯一性,仅保留少量位用于版本控制。
版本 5:与版本 3 类似,但使用 SHA-1 进行哈希处理,使其比版本 3 更安全。
变种
UUID 中的变体字段决定其布局和解释。最常见的变体包括:
-
变体 0:保留用于 NCS 向后兼容性。
-
变体 1:用于大多数 UUID 的标准布局。
-
变体 2:用于 DCE 安全 UUID,不太常见。
-
变体 3:保留供将来定义。
例子
对于 版本 4,UUID 可能如下所示:
550e8400-e29b-41d4-a716-446655440000
这里:
-
41d4 表示它是版本 4。
-
a7 代表变体,在本例中为常见的“Leach-Salz”变体。
UUID 是如何计算的
-
版本 1(基于时间):
- 时间戳通常是自 1582 年 10 月 15 日(公历改革日期)以来 100 纳秒间隔的数量。
- 节点是生成UUID的机器的MAC地址。
- 时钟序列有助于确保时钟时间变化时的唯一性(例如,由于系统重新启动)。
-
版本 3 和版本 5(基于名称):
- 命名空间(如 DNS 域)与名称(如文件路径或 URL)组合并进行哈希处理。
- 然后将哈希值(版本 3 的 MD5,版本 5 的 SHA-1)构造为 UUID 格式,确保正确设置版本和变体字段。
-
版本 4(基于随机):
- 为 UUID 的 122 位生成随机数或伪随机数。
- 版本和变体字段进行相应设置,确保符合 UUID 标准。
UUIDv4计算示例
第 1 步:生成 128 个随机位
假设我们生成以下 128 位随机值:
11001100110101101101010101111010101110110110111001011101010110110101111011010011011110100100101111001011
第 2 步:应用 UUIDv4 版本和变体
版本:用 0100(对于 UUID 版本 4)替换位 12-15(第 4 个字符)。
原来:1100变成0100→更新了这个位置的值。
变体:将第 9 个字节的位 6-7 替换为 10(对于 RFC 4122 变体)。
原来:11变成10→更新了这个位置的值。
第三步:格式化为十六进制
将128位二进制转换为5组十六进制:
- 32位组:11001100110101101101010101111010 → ccda55ba
- 16位组:1011101101101110 → b76e
- 16 位组:0100010101000101 → 4545(版本 4 为 0100)
- 16位组:1010110111110010 → adf2(其中10为变体)
- 48位组:11010011011110100100101111001011 → d39d25cb
第 4 步:合并组
最终的 UUID 如下所示:
ccda55ba-b76e-4545-adf2-d39d25cb