architecture - 什么时候你真正被迫使用 UUID 作为设计的一部分？

Question

我真的不明白UUID的意义。我知道碰撞的概率实际上为零，但是实际上为零也不是几乎不可能。

有人可以举一个你别无选择只能使用 UUID 的例子吗？从我见过的所有用途中，我可以看到一种没有 UUID 的替代设计。当然，设计可能会稍微复杂一些，但至少它不会出现非零的失败概率。

UUID 对我来说就像全局变量。全局变量有很多方法可以使设计更简单，但这只是懒惰的设计。

Answer 1

我为 Ruby 编写了 UUID 生成器/解析器，因此我认为自己对这个主题相当了解。 UUID 有四个主要版本:

版本 4 UUID 本质上只是从加密安全随机数生成器中提取的 16 字节随机数，并通过一些位操作来识别 UUID 版本和变体。这些发生冲突的可能性极小，但如果使用 PRNG 或者你碰巧运气真的真的真的真的真的很糟糕，就有可能发生这种情况。

版本 5 和版本 3 UUID 分别使用 SHA1 和 MD5 哈希函数，将命名空间与一段已经唯一的数据组合起来生成 UUID。例如，这将允许您从 URL 生成 UUID。仅当底层哈希函数也发生冲突时，这里的冲突才可能发生。

版本 1 UUID 是最常见的。他们使用网卡的 MAC 地址(除非被欺骗，否则应该是唯一的)，加上时间戳，加上通常的位旋转来生成 UUID。如果机器没有 MAC 地址，则使用加密安全随机数生成器生成 6 个节点字节。如果按顺序生成两个 UUID 的速度足够快，使得时间戳与前一个 UUID 匹配，则时间戳会增加 1。除非发生以下情况之一，否则不应发生冲突: MAC 地址被欺骗；一台机器运行两个不同的 UUID 生成应用程序，同时生成 UUID；两台没有网卡或没有用户级访问 MAC 地址的机器被赋予相同的随机节点序列，并在完全相同的时刻生成 UUID；我们用完了表示时间戳的字节并翻转回零。

实际上，这些事件都不会在单个应用程序的 ID 空间内偶然发生。除非您在互联网范围内接受 ID，或者在不受信任的环境中，恶意人员在 ID 冲突的情况下可能会做坏事，否则您不应该担心。重要的是要了解，如果您碰巧生成了与我相同的版本 4 UUID，则在大多数情况下，这并不重要。我在与您完全不同的 ID 空间中生成了 ID。我的应用程序永远不会知道碰撞，因此碰撞并不重要。坦率地说，在没有恶意行为者的单一应用程序空间中，地球上所有生命的灭绝早在发生碰撞之前就会发生，即使是在版本 4 UUID 上，即使您每秒生成相当多的 UUID。

另外，2^64 * 16 是 256 艾字节。例如，在单个应用程序空间中发生 ID 冲突的可能性为 50% 之前，您需要存储 256 艾字节的 ID。