在多个JVM上，Java'；随机UUID，碰撞的概率是多少？

我正在构建基于微服务的体系结构，其中多个微服务并行运行以实现水平可扩展性。 所有服务都使用相同的算法来生成UUID（UUID.randomUUID），一旦生成UUID，它就会保存在数据库中并返回给调用服务。几秒钟后，调用方发送请求，用UUID验证txn的状态

在关系数据库中，UUID是主键，我们看到了由不同服务生成的UUID的冲突。问题

跨JVM复制UUID的可能性有多大

在将冲突保存到DB之前，我们是否应该在代码中添加一些逻辑来验证冲突

跨JVM复制UUID的可能性有多大

这是可能的，但可能性非常小。关于生日问题的维基百科页面有一个可用于估计碰撞可能性的参数

例如，对于128位随机UUID（和一个高质量的随机数生成器），表中指出，要使碰撞概率达到1/1018，需要生成2.6 x 1010个UUID

在这篇文章的前面，你会发现关于计算。。。估计。。。概率

在将冲突保存到DB之前，我们是否应该在代码中添加一些逻辑来验证冲突

这实际上取决于您可能生成和存储的UUID数量，以及您愿意接受的冲突概率

但是，如果您担心发生冲突的可能性，则可以在相关数据库表中使UUID列成为唯一的键。由于硬件错误而导致事务失败的可能性要大于导致唯一性约束失败的冲突

---

后续问题：

我不确定这个概率是针对一台发电机还是多台发电机

生成器的数量不相关，前提是它们是>独立<随机数生成器

正如我们所看到的，与100万TXN发生了数百次碰撞

数学不会说谎。如果您已经看到了与一百万个事务的数百次冲突，那么其他一些事情是错误的。这些假设是不正确的

例如：

• 也许你使用的是弱PRNG
• 也许你正在使用一个固定的种子，或者在播种PRNG时使用了一个很差的熵源
• 也许您正在修改（例如缩短）UUID，从而大大减少其有效位计数
• 也许您的UUID生成方法中的某些东西导致UUID连续发布两次。。。有时候
• 也许对象在不应该被复制的时候被复制了。。。最终得到一个对象的两个副本，它们具有相同的UUID
• 也许有人/什么东西在伪造UUID

在你开始怀疑数学之前，你需要检查很多东西

我怀疑所有4个服务都使用相同的算法，概率会增加

---

正如我所说，发电机的数量并不会改变数学计算。

目前大多数实际服务实际上只是假装碰撞不是一件事——因为概率很低。对于与散列的冲突（如SHA或MD5）也是如此。显然，这取决于您计划处理的数量，但通常情况下，这一事实在大多数情况下确实被忽略。我们正在使用4个微服务测试1M事务，并且由于UUID冲突，我们每次可以有几百次失败。感谢链接，但我不确定这一概率是针对一个生成器还是多个生成器？正如我们所看到的，与100万TXN发生了数百次碰撞。我怀疑所有4个服务都使用相同的算法，概率会增加。谢谢@stephen，我现在找到了根本原因。正如您所提到的，我在DB端对日志进行了更多的挖掘，发现有一些脚本正在运行，这造成了这种混乱。谢谢你的帮助。