Architecture 什么时候您真正被迫将UUID作为设计的一部分？

我真的不明白这有什么意义。我知道碰撞的概率实际上是零，但实际上零甚至不是不可能的

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

---

UUID闻起来像是全局变量。全局变量有许多简化设计的方法，但这只是一种懒惰的设计。

在我的上一份工作中，我们从第三方获得了唯一标识为UUID的对象。我加入了一个UUID->long integer查找表，并使用long integer作为主键，因为这样做要快得多。

一个典型的例子是在两个数据库之间进行复制

DB（A）插入一个int ID为10的记录，同时DB（B）创建一个int ID为10的A记录。这是一次碰撞

对于UUID，这不会发生，因为它们不匹配。（几乎可以肯定）

强调“合理”或如你所说的“有效”：现实世界的运作方式已经足够好了。为了弥补“实际独特”和“真正独特”之间的差距，所涉及的计算工作量是巨大的。唯一性是一条收益递减的曲线。在这条曲线的某个点上，在“足够独特”仍然可以承受的地方和我们的曲线非常陡峭之间有一条线。增加更多独特性的成本变得相当大。无限的唯一性有无限的代价

---

相对而言，UUID/GUID是一种计算快速且简单的生成ID的方法，可以合理地假设该ID是唯一的。这在许多需要集成以前未连接系统的数据的系统中非常重要。例如：如果您有一个在两个不同平台上运行的内容管理系统，但在某些情况下需要将内容从一个系统导入另一个系统。您不希望ID发生更改，因此来自系统A的数据之间的引用保持不变，但您不希望与在系统B中创建的数据发生任何冲突。UUID解决了这一问题。

创建UUID从来都不是绝对必要的。然而，有一个标准是很方便的，离线用户可以各自生成一个具有很低冲突概率的密钥

这有助于数据库复制解决方案等

在线用户可以很容易地为某些东西生成唯一的密钥，而不会产生开销或冲突的可能性，但UUID并不是这样做的

总之，关于碰撞概率的一个词，摘自维基百科：

从这些数字来看，一个人每年遭受打击的风险 据估计，陨石撞击地球的几率为170亿分之一，相当于 有可能在一年内创造几十万亿个UUID 有一个副本的。换句话说，只有在创造了10亿美元之后 在接下来的100年中，UUID每秒产生一次的概率 只有一个复制品大约占50%

---

使用版本1算法，在同一MAC地址每毫秒生成少于10个UUID的约束下，似乎不可能发生冲突

从概念上讲，原始版本（版本1） UUID的生成方案是 将UUID版本与 所选计算机的MAC地址 生成UUID，并使用 100纳秒间隔数 自采用格里高利法以来 西方的日历。实际上 实际算法比较复杂。 这项计划在许多国家受到批评 它不够“不透明”； 它揭示了 生成UUID和 它这样做的时间

---

如果我误解了它的工作原理，有人会纠正我的错误

UUID为您提供的另一件非常困难的事情是在无需咨询或与中央机构协调的情况下获得唯一标识符。在没有某种托管基础设施的情况下获得这样的东西的一般问题是UUID所解决的问题

我已经读到，根据生日悖论，一旦生成2^64个UUID，发生UUID冲突的几率为50%。现在2^64是一个相当大的数字，但是50%的碰撞概率似乎太高了（例如，在5%的碰撞概率之前，需要存在多少UUID——即使这看起来也太高了）

这种分析有两个问题：

UUID不是完全随机的-UUID的主要组件是基于时间和/或位置的。因此，要想真正有机会发生碰撞，碰撞的UUID需要在同一时间从不同的UUID生成器生成。我要说的是，虽然有一个合理的机会，几个UUID可能会同时生成，但有足够多的其他问题（包括位置信息或随机位），使得这个非常小的UUID集之间发生冲突的可能性几乎不可能

严格地说，UUID只需要在其他UUID集合中是唯一的，以便与之进行比较。如果您正在生成一个UUID用作数据库密钥，那么在另一个邪恶的世界中，是否使用同一个UUID来标识COM接口并不重要。就像半人马座阿尔法星上有一个叫“迈克尔·伯尔”的人（或物）一样，这不会引起混乱

---

关于UUID==惰性设计的

---

我不同意你挑起争端。如果重复的UUID在统计上是不可能的，并且数学证明了，那么为什么要担心呢？花时间围绕小型N UUID生成系统进行设计是不切实际的，总有十几种其他方法可以改进您的系统。

也有一种非零概率，即