GUID在100%的时间内都是唯一的吗?
它会在多个线程中保持唯一吗?
答案 0 :(得分:382)
虽然每个生成的GUID都不是 保证是独一无二的,总数 唯一键的数量(2 128 或 3.4×10 38 )是如此之大,以至于相同数量的概率 生成两次非常小。对于 例如,考虑可观察性 宇宙,包含约5×10 22 星星;那么每个明星都可以拥有 6.8×10 15 普遍独特的GUID。
来自Wikipedia。
这些是关于如何制作GUID(对于.NET)以及如何在正确的情况下获得相同guid的一些好文章。
https://ericlippert.com/2012/04/24/guid-guide-part-one/
https://ericlippert.com/2012/04/30/guid-guide-part-two/
https://ericlippert.com/2012/05/07/guid-guide-part-three/
答案 1 :(得分:60)
简单的答案是肯定的。
Raymond Chen在GUID上写了great article,为什么GUID的子串不保证唯一。本文深入介绍了生成GUID的方式以及它们用于确保唯一性的数据,这些内容在解释为什么时应该有一定的篇幅: - )
答案 2 :(得分:55)
如果您害怕相同的GUID值,则将其中两个放在一起。
Guid.NewGuid().ToString() + Guid.NewGuid().ToString();
如果你太偏执了,就放三个。
答案 3 :(得分:34)
作为旁注,我正在玩Windows XP中的Volume GUID。这是一个非常模糊的分区布局,有三个磁盘和十四个卷。
\\?\Volume{23005604-eb1b-11de-85ba-806d6172696f}\ (F:)
\\?\Volume{23005605-eb1b-11de-85ba-806d6172696f}\ (G:)
\\?\Volume{23005606-eb1b-11de-85ba-806d6172696f}\ (H:)
\\?\Volume{23005607-eb1b-11de-85ba-806d6172696f}\ (J:)
\\?\Volume{23005608-eb1b-11de-85ba-806d6172696f}\ (D:)
\\?\Volume{23005609-eb1b-11de-85ba-806d6172696f}\ (P:)
\\?\Volume{2300560b-eb1b-11de-85ba-806d6172696f}\ (K:)
\\?\Volume{2300560c-eb1b-11de-85ba-806d6172696f}\ (L:)
\\?\Volume{2300560d-eb1b-11de-85ba-806d6172696f}\ (M:)
\\?\Volume{2300560e-eb1b-11de-85ba-806d6172696f}\ (N:)
\\?\Volume{2300560f-eb1b-11de-85ba-806d6172696f}\ (O:)
\\?\Volume{23005610-eb1b-11de-85ba-806d6172696f}\ (E:)
\\?\Volume{23005611-eb1b-11de-85ba-806d6172696f}\ (R:)
| | | | |
| | | | +-- 6f = o
| | | +---- 69 = i
| | +------ 72 = r
| +-------- 61 = a
+---------- 6d = m
并不是GUID非常相似,而是所有GUID都包含字符串“mario”的事实。这是巧合还是背后有解释?
现在,当GUID中的googling for part 4发现大约有125.000次点击时,音量GUID。
结论:说到卷GUID,它们并不像其他GUID那样独特。
答案 4 :(得分:26)
是的,GUID应该始终是唯一的。它基于硬件和时间,加上一些额外的位,以确保它是独一无二的。我确信理论上可能最终得到两个相同的,但在现实场景中极不可能。
以下是Raymond Chen关于Guids的精彩文章:
https://blogs.msdn.com/oldnewthing/archive/2008/06/27/8659071.aspx
答案 5 :(得分:22)
不应该发生。但是,当.NET负载很重时,可能会出现重复的guid。我有两个不同的Web服务器使用两个不同的SQL服务器。我去合并数据,发现我有1500万guid和7个重复。
答案 6 :(得分:20)
Guids在统计上是独一无二的。生成相同Guid的两个不同客户端的几率是无限小的(假设Guid生成代码中没有错误)。您可能会担心由于宇宙射线导致的处理器故障,并且今天确定2 + 2 = 5。
分配新guid的多个线程将获得唯一值,但是你应该得到你正在调用的函数是线程安全的。这个环境是什么?
答案 7 :(得分:16)
Eric Lippert撰写了一系列关于GUID的非常有趣的文章。
世界上有2个 30 个人电脑(和 当然有很多手持设备或非PC计算设备 或多或少相同级别的计算能力,但让我们忽略 那些)。让我们假设我们将所有这些PC放在世界上 生成GUID的任务;如果每个人可以生成2个 20 GUIDs 然后仅约2 72 秒 - 一百五十 万亿年 - 你将有非常高的生成机会的机会 与您的特定GUID冲突。碰撞的几率得到了 仅仅三十万亿年就相当不错了。
答案 8 :(得分:14)
理论上,不,它们不是唯一的。可以一遍又一遍地生成相同的guid。然而,它发生的可能性非常低,你可以认为它们是独一无二的。
我之前已经读过这样的机会很低,你真的应该强调别的东西 - 比如你的服务器自发地燃烧或你的代码中的其他错误。也就是说,假设它是唯一的,并且不构建任何代码来“捕获”重复项 - 将时间花在更有可能发生的事情上(即任何其他)。
我made an attempt来描述GUID对我的博客受众(非技术家庭成员)的有用性。从那里(通过维基百科),生成重复GUID的几率:
答案 9 :(得分:9)
似乎没有提到它发生概率的实际数学。
首先,我们假设我们可以使用整个128位空间(Guid v4仅使用122位)。
我们知道在n
选秀权中没有获得重复的一般概率是:
(1-1 / 2 128 )(1-2 / 2 128 )...(1-(N-1)/ 2 128功能)
因为2 128 比n
大得多,我们可以将其近似为:
(1-1 / 2 128 ) N(N-1)/ 2
因为我们可以假设n
远大于0,我们可以将其近似为:
(1-1 / 2 128 ) N ^ 2/2
现在我们可以把它等同于“可接受的”概率,比方说1%:
(1-1 / 2 128 ) n ^ 2/2 = 0.01
我们为n
求解并得到:
n = sqrt(2 * log 0.01 / log(1-1 / 2 128 ))
哪个Wolfram Alpha 5.598318×10 19
为了对这个数字进行透视,我们可以使用10000台机器,每台机器都有4核CPU,执行4Ghz并花费10000个周期来生成Guid而不执行任何其他操作。然后它们需要大约111年才能生成副本。
答案 10 :(得分:7)
来自http://www.guidgenerator.com/online-guid-generator.aspx
什么是GUID?
GUID(或UUID)是“全球唯一标识符”(或“通用唯一标识符”)的首字母缩写。它是一个128位整数,用于标识资源。术语GUID通常由使用Microsoft技术的开发人员使用,而UUID则用于其他任何地方。
GUID有多独特?
128位是足够大的,并且生成算法足够独特,如果1年内生成每秒1,000,000,000个GUID,则重复的概率仅为50%。或者,如果地球上的每个人都产生了600,000,000个GUID,那么重复的概率只有50%。
答案 11 :(得分:4)
我遇到了重复的GUID。
我使用Neat Receipts桌面扫描仪,它附带专有的数据库软件。该软件具有同步到云功能,并且在同步时我一直收到错误。在日志上看到了一条令人敬畏的线路:
"错误":[{"代码":1,"消息":" creator_guid:已经是 采取"" GUID":" C83E5734-D77A-4B09-B8C1-9623CAC7B167"}]}
我有点难以置信,但当然,当我找到进入我的本地neatworks数据库的方法并删除包含该GUID的记录时,错误就停止了。
所以用轶事证据回答你的问题,不。可以复制。但它可能发生的原因不是偶然,而是由于标准做法没有以某种方式加以遵守。 (我不是那么幸运)但是,我不能肯定地说。这不是我的软件。
他们的客户支持极其礼貌和乐于助人,但他们之前从未遇到过这个问题,因为在与他们通电3个多小时后,他们找不到解决方案。 (FWIW,我对Neat印象非常深刻,这个小故障,无论多么令人沮丧,都没有改变我对他们产品的看法。)
答案 12 :(得分:4)
如果您的系统时钟设置正确并且没有缠绕,并且您的NIC有自己的MAC(即您没有设置自定义MAC)并且您的NIC供应商尚未回收MAC(它们不是应该这样做,但已知会发生这种情况),如果系统的GUID生成功能正确实现,那么您的系统将永远不会生成重复的GUID。
如果世界上每个生成GUID的人都遵循这些规则,那么您的GUID将是全球唯一的。
在实践中,违反规则的人数很少,他们的GUID不太可能“逃脱”。冲突在统计上是不可能的。
答案 13 :(得分:3)
GUID在100%的时间内都是唯一的吗?
无法保证,因为有多种方法可以生成一个。但是,您可以尝试计算创建两个相同的GUID的机会,并且您明白了:GUID有128位,因此,有2个 128 不同的GUID - 多强大>超过已知宇宙中的恒星。请阅读wikipedia article了解详情。
答案 14 :(得分:3)
MSDN:
新Guid的值全部为零或等于任何其他Guid的概率非常低。
答案 15 :(得分:1)
GUID算法通常根据v4 GUID规范实现,该规范本质上是伪随机字符串。遗憾的是,这些属于维基百科的“可能非唯一”类别(我不知道为什么这么多人会忽略这一点):“......其他GUID版本具有不同的唯一性属性和概率,从保证唯一性到可能的非唯一性。“
V8的JavaScript Math.random()
的伪随机属性在唯一性上是可怕的,碰撞通常仅在几千次迭代后发生,但V8并不是唯一的罪魁祸首。我已经使用v4 GUID的PHP和Ruby实现看到了真实的GUID冲突。
因为在多个客户端和服务器集群中扩展ID生成变得越来越普遍,熵受到很大影响 - 使用相同随机种子生成ID升级的可能性(时间通常用作伪随机生成器中的随机种子,并且GUID冲突从“可能非唯一”升级到“非常可能导致很多麻烦”。
为了解决这个问题,我开始创建一个可以安全扩展的ID算法,并更好地保证防止冲突。它通过使用时间戳,内存客户端计数器,客户端指纹和随机字符来实现。这些因素的组合产生了一种附加的复杂性,即使您在多个主机上进行扩展,也能抵抗碰撞:
答案 16 :(得分:1)
我经历过GUID在多线程/多进程单元测试期间不是唯一的(也是?)。我想这与所有其他的相同,伪随机发生器的相同种子(或缺乏播种)有关。我用它来生成唯一的文件名。我发现操作系统在这方面要好得多:)
您询问GUID是否100%唯一。这取决于它必须是唯一的GUID数量。随着GUID的数量接近无穷大,重复GUID的概率接近100%。
答案 17 :(得分:1)
从更一般的意义上讲,这被称为生日问题"或者"生日悖论"。维基百科有一个非常好的概述: Wikipedia - Birthday Problem
非常粗略地说,池的大小的平方根是一个粗略的近似值,当你可以预期有50%的重复几率。该文章包括池大小和各种概率的概率表,包括2 ^ 128的行。因此,对于1%的碰撞概率,您可能会随机选择2.6 * 10 ^ 18个128位数字。 50%的几率需要2.2 * 10 ^ 19个选择,而SQRT(2 ^ 128)需要1.8 * 10 ^ 19。
当然,这只是一个真正随机过程的理想情况。正如其他人所提到的那样,很多都是在随机方面 - 发电机和种子有多好?如果有一些硬件支持可以帮助这个过程,那将是更好的,除了任何可以欺骗或虚拟化之外,这将是更加防弹。我怀疑这可能是为什么不再包含MAC地址/时间戳的原因。
答案 18 :(得分:1)
要获得更好的结果,最好的方法是在GUID后面附加时间戳(只需确保它保持唯一)
Guid.NewGuid().ToString() + DateTime.Now.ToString();
答案 19 :(得分:0)
“ GUID是否100%唯一?”的答案仅仅是“否” 。
如果要GUID具有100%的唯一性,请执行以下操作。
答案 20 :(得分:0)
最困难的部分不是生成重复的Guid。
最难的部分是设计一个数据库,用于存储所有生成的数据库,以检查它是否实际上是重复的。
从维基百科:
例如,为了产生至少一次碰撞的50%概率而需要生成的随机版本4 UUID的数量为2.71亿五千万,计算如下:
这个数字相当于在大约85年的时间里每秒产生10亿个UUID,而包含这么多UUID(每个UUID为16字节)的文件大约为45艾字节,比目前最大的数据库大很多倍,大约数百PB的大小
答案 21 :(得分:0)
GUID代表全局唯一标识符
简介: (线索就是名字)
详细信息: GUID设计为唯一;它们是根据计算机时钟和计算机本身使用随机方法计算的,如果您在同一台计算机上同一毫秒创建许多GUID,则它们可能会匹配,但对于几乎所有正常操作,都应将它们视为唯一。>
答案 22 :(得分:0)
足够的 GUID 可以为可见宇宙中每颗恒星周围的每个假设行星上的每个假设沙粒分配一个。
足够了,如果世界上的每台计算机在 200 年内每秒生成 1000 个 GUID,那么可能(可能)会发生冲突。
鉴于当前本地使用 GUID 的数量(例如每个数据库每个表一个序列),对于我们有限的生物(以及寿命通常不到十年的机器,如果不是一个手机一两年)。
...我们现在可以关闭这个帖子吗?