GUID 100%是唯一的吗?

它会在多个线程中保持唯一吗?


当前回答

在更广泛的意义上,这被称为“生日问题”或“生日悖论”。维基百科有一个很好的概述: 维基百科-生日问题

粗略地说,池大小的平方根是一个粗略的近似值,即您可以期望有50%的重复机会。这篇文章包含了一个关于池大小和各种概率的概率表,包括2^128的一行。所以对于1%的碰撞概率,你可以随机选择2.6*10^18个128位数字。50%的概率需要2.2*10^19次选择,而根号(2^128)是1.8*10^19次选择。

当然,这只是一个真正随机过程的理想情况。正如其他人所提到的,很多事情都取决于随机方面——生成器和种子有多好?如果有一些硬件支持来帮助这个过程,那就太好了,这将更加防弹,除非任何东西都可能被欺骗或虚拟化。我怀疑这可能是MAC地址/时间戳不再被合并的原因。

其他回答

GUID 100%是唯一的吗?

不能保证,因为有几种方法可以生成一个。然而,您可以尝试计算创建两个完全相同的GUID的几率,您就会明白:一个GUID有128位,因此,有2128个不同的GUID——比已知宇宙中的恒星要多得多。阅读维基百科的文章了解更多细节。

在更广泛的意义上,这被称为“生日问题”或“生日悖论”。维基百科有一个很好的概述: 维基百科-生日问题

粗略地说,池大小的平方根是一个粗略的近似值,即您可以期望有50%的重复机会。这篇文章包含了一个关于池大小和各种概率的概率表,包括2^128的一行。所以对于1%的碰撞概率,你可以随机选择2.6*10^18个128位数字。50%的概率需要2.2*10^19次选择,而根号(2^128)是1.8*10^19次选择。

当然,这只是一个真正随机过程的理想情况。正如其他人所提到的,很多事情都取决于随机方面——生成器和种子有多好?如果有一些硬件支持来帮助这个过程,那就太好了,这将更加防弹,除非任何东西都可能被欺骗或虚拟化。我怀疑这可能是MAC地址/时间戳不再被合并的原因。

为了获得更好的结果,最好的方法是将GUID与时间戳附加在一起(只是为了确保它保持唯一)

Guid.NewGuid().ToString() + DateTime.Now.ToString();

GUID算法通常根据v4 GUID规范实现,它本质上是一个伪随机字符串。可悲的是,这些都属于“可能非唯一”的类别,来自维基百科(我不知道为什么这么多人忽略了这一点):“……其他GUID版本有不同的唯一性属性和概率,从保证唯一性到可能的非唯一性。”

V8的JavaScript Math.random()的伪随机属性在唯一性方面很糟糕,通常在几千次迭代之后就会发生冲突,但V8并不是唯一的罪魁祸首。我曾经使用PHP和Ruby实现的v4 GUID在现实世界中遇到过GUID冲突。

因为在多个客户端和服务器集群上扩展ID生成变得越来越普遍,熵会受到很大的冲击——使用相同的随机种子生成ID的几率会增加(在伪随机生成器中,时间经常被用作随机种子),GUID冲突也会从“可能不是唯一的”升级为“很可能造成很多麻烦”。

为了解决这个问题,我开始创建一个可以安全扩展的ID算法,并更好地保证不发生碰撞。它通过使用时间戳、内存中的客户端计数器、客户端指纹和随机字符来实现这一点。这些因素的组合产生了一种附加的复杂性,它特别抗碰撞,即使你将它扩展到多个主机:

http://usecuid.org/

最难的部分不是生成重复的Guid。

最难的部分是设计一个数据库来存储所有生成的数据,以检查它是否实际上是重复的。

从维基:

例如,为了有至少一次碰撞的50%概率,需要生成的随机版本4 uuid的数量为2.71 quintillion,计算如下:

在这里输入图像描述

这个数字相当于在大约85年的时间里每秒生成10亿个UUID,而包含这么多UUID的文件(每个UUID 16个字节)大约是45艾字节,比目前存在的最大数据库(几百pb量级)大很多倍