使用哪个 UUID 版本？答案

【问题标题】：Which UUID version to use?使用哪个 UUID 版本？
【发布时间】：2013-12-18 23:21:44
【问题描述】：

您应该使用哪个版本的 UUID？我看到很多线程解释了每个版本的含义，但我无法弄清楚什么最适合哪些应用程序。

【问题讨论】：

你的选择是什么？
任何适用于 python 的东西。所以我猜这是docs.python.org/2/library/uuid.html。 1,3,4,5。
如果您对版本 3 和 5 感到好奇，请参阅此问题，Generating v5 UUID. What is name and namespace?。

标签： uuid

【解决方案1】：

有两种不同的方式来生成 UUID。

如果您只需要一个唯一的 ID，则需要版本 1 或版本 4。

版本 1：这会根据网卡 MAC 地址和当前时间生成唯一 ID。如果这些东西中的任何一个以任何方式敏感，请不要使用它。该版本的优势在于，在查看由您信任的机器生成的 UUID 列表时，您可以轻松了解是否有许多 UUID 是由同一台机器生成的，或者推断它们之间的某种时间关系。
版本 4：这些是由随机（或伪随机）数字生成的。如果您只需要生成一个 UUID，这可能就是您想要的。此版本的优势在于，当您调试并查看与 UUID 匹配的一长串信息时，可以更快地发现匹配项。

如果您需要从给定名称生成可重现的 UUID，则需要版本 3 或版本 5。

版本 3：这会根据命名空间和名称的 MD5 哈希生成唯一 ID。如果您需要向后兼容（与从名称生成 UUID 的另一个系统），请使用它。
版本 5：这会根据命名空间和名称的 SHA-1 哈希生成唯一 ID。这是更安全的版本。

【讨论】：

我要补充一点：如果您需要从给定名称生成 reproducible UUID，则需要版本 3 或版本 5。如果您为该算法提供相同的输入，它将生成相同的输出。
在云计算环境（例如 AWS 或 GAE）中，版本 1 的弱点似乎被忽略了。随着时间的推移，可能有数千个不同的 MAC 地址应用于给定应用程序的 UUID 生成器，从而消除了可预测性和/或可追溯性。
@user239558 鉴于 UUID 的目标是其唯一性，UUIDv5 仍然是首选。
关于“不推荐”版本 1 的评论过于简单化。在许多情况下，这些确实很好而且更可取。但是，如果您担心从 UUID 泄露这些信息中的任何一项，这些信息可能会提供给不可信的参与者：（a）创建 UUID 的机器的 MAC 地址，或（b）创建时的日期时间，然后避免使用版本 1。如果这两条信息不敏感，那么版本 1 是一个很好的选择。
第 2 版发生了什么？

【解决方案2】：

由于尚未提及：如果您希望能够按创建时间对实体进行排序，而无需单独的明确时间戳，则可以使用 uuidv1。虽然这不是 100% 精确，在许多情况下也不是最好的方法（由于缺乏明确性），但在某些情况下它会派上用场，例如当您使用 Cassanda 数据库时。

【讨论】：

【解决方案3】：

Postgres documentation 描述了UUIDs 之间的区别。其中几个：

V3：

uuid_generate_v3(namespace uuid, name text) - 此函数使用指定的输入名称在给定命名空间中生成版本 3 UUID。

V4：

uuid_generate_v4 - 此函数生成版本 4 UUID，它完全来自随机数。

【讨论】：

【解决方案4】：

如果您想要一个随机数，请使用随机数库。如果你想要一个有效的 0.00 的唯一标识符......这里还有更多的 0......001% 的碰撞几率，你应该使用 UUIDv1。有关 UUIDv3 和 v5，请参阅 Nick 的帖子。

UUIDv1 不安全。它不应该是。它意味着是唯一的，而不是不可猜测的。 UUIDv1 使用当前时间戳，加上一个机器标识符，再加上一些随机的东西来生成一个永远不会再由该算法生成的数字。这适用于事务 ID（即使每个人都在进行数百万次事务/秒）。

说实话，我不明白为什么 UUIDv4 存在...从阅读 RFC4122 来看，该版本似乎并没有消除冲突的可能性。它只是一个随机数生成器。如果这是真的，那么世界上两台机器很有可能最终创建相同的“UUID”v4（引用是因为没有保证通用唯一性的机制）。在那种情况下，我认为该算法不属于描述生成唯一值的方法的 RFC。它属于关于生成随机性的 RFC。对于一组随机数：

chance_of_collision = 1 - (set_size! / (set_size - tries)!) / (set_size ^ tries)

【讨论】：

除非you generate a billion UUIDs every second for a century and win a coin flip，否则您不会看到两个 UUID 版本 4 实现发生冲突。请记住，set_size 是 2^122，非常大。
V4 算法不是串行的，这意味着 v4 生成的前两个 UUID 有可能匹配。仅仅因为有很多选项，并不意味着您必须在生成重复之前用完独特的选项。这可能随时发生。
你没有真正做数学。我们（作为一个物种）每秒不会产生 10 亿个 UUID。因此，距离第一次碰撞（平均）还有 100 年以上的时间。
V4“可能”发生碰撞，但对于大多数用例来说，这种风险非常低，值得冒险。回复：“世界上的两台机器最终会创建相同的 'UUID'v4”，嗯，当然，但这不是问题，因为世界上大多数使用 UUID 的机器在不同的上下文中使用它们。我的意思是，如果我为自己的内部应用程序生成与您为内部应用程序生成的 UUID 相同的 UUID，那么没关系。只有当它们发生在相同的上下文中时，碰撞才有意义。（请记住，即使在一个应用程序中，许多 UUID 不必在整个应用程序中都是唯一的，只要它们使用的上下文是唯一的）
所以听起来，如果您不需要您的 Guid 是安全的，请使用版本 1。如果您需要它的安全，并且觉得幸运（或者真的，不要觉得不幸运）使用版本4.

【解决方案5】：

这是一个非常笼统的问题。一个答案是：“这取决于您希望生成什么样的 UUID”。但更好的是：“好吧，在我回答之前，你能告诉我们为什么你需要编写自己的 UUID 生成算法，而不是调用大多数现代操作系统提供的 UUID 生成功能吗？”

这样做更容易、更安全，而且您可能不需要自己生成，为什么还要编写实现代码呢？在这种情况下，答案就变成使用你的操作系统、编程语言或框架提供的任何东西。例如，在 Windows 中，有 CoCreateGuid 或 UuidCreate 或可从众多正在使用的框架中获得的各种包装器之一。在 Linux 中有uuid_generate。

如果您出于某种原因绝对需要生成自己的 UUID，那么至少要远离生成 v1 和 v2 UUID。把这些做好是很棘手的。相反，坚持使用 v3、v4 或 v5 UUID。

更新：在评论中，您提到您正在使用 Python 并链接到 this。查看提供的界面，最简单的选项是通过调用uuid.uuid4() 生成一个 v4 UUID（即从随机数据创建的 UUID）。

如果您有一些数据需要（或可以）散列以从中生成 UUID，那么您可以使用 v3（依赖于 MD5）或 v5（依赖于 SHA1）。生成 v3 或 v5 UUID 很简单：首先选择您要生成的 UUID 类型（您可能应该选择 v5），然后选择适当的命名空间并使用您要用于从中生成 UUID 的数据调用函数。例如，如果您正在对 URL 进行哈希处理，您将使用 NAMESPACE_URL:

uuid.uuid3(uuid.NAMESPACE_URL, 'https://ripple.com')

请注意，此 UUID 将不同于同一 URL 的 v5 UUID，其生成方式如下：

uuid.uuid5(uuid.NAMESPACE_URL, 'https://ripple.com')

v3 和 v5 URL 的一个很好的特性是它们应该在实现之间可以互操作。换句话说，如果两个不同的系统正在使用符合 RFC4122 的实现，那么如果所有其他条件都相同（即生成相同版本的 UUID），它们将（或至少应该）都生成相同的 UUID ，具有相同的命名空间和相同的数据）。此属性在某些情况下（尤其是在内容可寻址存储场景中）非常有用，但可能不适用于您的特定情况。

【讨论】：

我猜这是因为 OP 没有问：我如何“编写 [我的] 自己的 UUID 生成算法，而不是调用大多数现代操作系统提供的 UUID 生成功能？”
除此之外，我认为这是对 UUIDv3 和 v5 的一个很好的解释。请参阅下面的回答，了解为什么我认为 v1 可能是一个不错的选择。
什么是 NAMESPACE_URL ？这是我能得到的变量吗？从哪里来？
@stackdave NAMESPACE_URL 是一个 UUID，通常等于 6ba7b811-9dad-11d1-80b4-00c04fd430c8，遵循 RFC-4122 第 30 页上的建议。
sha256.update(something.getBytes(charset)); sha256.update(somethingElse.getBytes(charset)); byte[] hash = sha256.digest(salt); return UUID.nameUUIDFromBytes(hash).toString(); 这是 v3 吗？他们生成相同的 UUID 吗？ RFC4122 ?