UUID/GUID:它们是什么以及何时使用
· 12分钟阅读
目录
深入理解UUID
如果你曾经参与过处理大量数据的软件项目,你可能遇到过UUID这个术语,即通用唯一标识符。这些128位标识符在你需要确保每条数据在不同系统、数据库甚至组织之间都是唯一的时候,简直是救星。
可以把UUID想象成你给事物起的非常长的名字,这样就不会有人拥有相同的名字。它们就像数据的条形码,看起来像这样:550e8400-e29b-41d4-a716-446655440000。这个结构由32个十六进制字符组成,分为五组,用连字符分隔。
UUID的美妙之处在于它们的统计唯一性。有2128种可能的组合(大约340涧),生成重复UUID的概率极其微小,在实际应用中可以忽略不计。换个角度说,你可以在接下来的100年里每秒生成10亿个UUID,仍然几乎没有碰撞的可能。
为什么UUID在现代软件中很重要
想象一个装满产品的巨大仓库——每件物品都需要一个唯一的标签。UUID确保每个产品都有自己独特的标识符,即使系统同时处理多个任务也不会混淆。这对于分散在不同位置、没有中央机构分配ID的系统特别有价值。
它们通过防止ID冲突来帮助分布式应用程序,允许每个系统独立运行而不会干扰其他系统的数据。这种去中心化的ID生成方法使UUID在微服务架构、分布式数据库和云原生应用程序中不可或缺。
专业提示:UUID在微软生态系统中也被称为GUID(全局唯一标识符)。虽然存在细微的技术差异,但这些术语在实践中经常互换使用。
UUID结构和版本
在幕后,UUID有一个精心设计的结构来帮助避免冲突。根据版本的不同,它们的生成方式包括时间戳、主机标识符和随机数等信息位。这种设置有助于保持一切唯一,这在处理跨不同平台的系统时至关重要。
UUID组件分解
标准UUID遵循以下格式:xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
- 时间低位(8个十六进制数字):时间戳的前32位
- 时间中位(4个十六进制数字):时间戳的中间16位
- 时间高位和版本(4个十六进制数字):时间戳的高12位加上4位版本号
- 时钟序列和保留位(4个十六进制数字):时钟序列和变体位
- 节点(12个十六进制数字):48位节点标识符(通常是MAC地址或随机值)
UUID版本说明
UUID规范定义了几个版本,每个版本都针对不同的用例进行了优化。了解这些版本有助于你为应用程序选择合适的版本。
| 版本 | 生成方法 | 最适合 | 可排序 |
|---|---|---|---|
| 版本1 | 时间戳 + MAC地址 | 跟踪创建时间、审计日志 | 是 |
| 版本3 | 命名空间 + 名称的MD5哈希 | 从URL/名称生成确定性ID | 否 |
| 版本4 | 随机数 | 通用目的、最大隐私 | 否 |
| 版本5 | 命名空间 + 名称的SHA-1哈希 | 确定性ID(比v3更安全) | 否 |
| 版本6 | 重新排序的时间戳 + MAC | 数据库友好的可排序ID | 是 |
| 版本7 | Unix时间戳 + 随机 | 不含MAC的现代可排序ID | 是 |
版本4:随机UUID
当人们谈论版本4 UUID时,他们指的是完全随机的ID,没有时间戳或主机标识符的痕迹。它们非常适合隐私很重要的情况,你不希望泄露有关ID生成时间或地点的任何信息。
版本4是最常用的UUID版本,因为它简单、安全,并且不需要系统之间的任何协调。随机性来自密码学安全的随机数生成器,确保不可预测性。
使用我们的UUID生成器工具尝试生成你自己的UUID,看看它们在实践中是如何工作的。
版本1和6:基于时间的UUID
版本1 UUID包含时间戳和生成机器的MAC地址。这使它们可以按创建时间排序,这对数据库和日志系统很有用。然而,包含MAC地址会引发隐私问题,因为它会泄露有关生成机器的信息。
版本6是一个较新的规范,通过重新排序时间戳位来解决版本1的一些缺点,使UUID自然可排序。这显著提高了数据库索引性能。
版本7:现代选择
版本7是UUID家族的最新成员,代表了两全其美。它使用Unix时间戳实现可排序性,但用随机数据替换MAC地址以保护隐私。这使它成为需要性能和安全性的现代分布式系统的理想选择。
许多开发人员现在选择版本7作为新项目的默认UUID版本,因为它结合了基于时间排序的优势和随机生成的隐私性。
争论:UUID与自增ID
数据库设计中最激烈的争论之一是使用UUID还是传统的自增整数作为主键。两种方法都有其优点,正确的选择取决于你的具体需求。
UUID的优势
- 去中心化生成:不需要中央机构或数据库序列
- 合并友好:易于合并来自多个源的数据而不会发生ID冲突
- 通过模糊性提高安全性:非顺序ID使猜测有效标识符变得更困难
- 离线生成:可以在数据库插入之前创建ID
- 分布式系统:非常适合微服务和分片数据库
- 无竞态条件:多个系统可以同时生成ID
自增ID的优势
- 更小的大小:4-8字节,而UUID为16字节
- 更好的索引性能:顺序整数对缓存更友好
- 人类可读:在对话和调试中更容易引用
- 可预测的排序:自然的时间顺序排序
- 更少的存储:在大型数据库中节省大量空间
- 更快的连接:整数比较的计算成本更低
性能比较
| 指标 | 自增 | UUID v4 | UUID v7 |
|---|---|---|---|
| 存储大小 | 4-8字节 | 16字节 | 16字节 |
| 索引性能 | 优秀 | 差(随机) | 好(顺序) |
| 插入速度 | 快 | 较慢(碎片化) | 快 |
| 分布式友好 | 否 | 是 | 是 |
| URL友好性 | 优秀 | 好 | 好 |
快速提示:如果你使用PostgreSQL,可以考虑使用uuid-ossp扩展来高效生成UUID,或使用PostgreSQL 13+内置的较新gen_random_uuid()函数。
混合方法
许多现代应用程序使用混合策略:内部数据库操作使用自增ID,外部API使用UUID。这为你提供了内部整数的性能优势,同时向外部世界公开非顺序的安全标识符。
例如,你的数据库可能有一个带自增整数的id列和一个单独的uuid列,用于API响应和URL。这种方法在电子商务平台和SaaS应用程序中很常见。
何时使用UUID:理想场景
了解UUID在何时发挥作用有助于你做出明智的架构决策。以下是UUID不仅有益而且通常必不可少的场景。
分布式系统和微服务
在微服务架构中,不同的服务通常需要独立创建记录。UUID消除了生成ID时服务之间协调的需要。每个服务都可以创建自己的标识符,而不必担心与其他服务发生冲突。
这在事件驱动架构中特别有价值,其中事件需要可由系统中任何服务生成的唯一标识符。
数据同步和复制
当你在多个