GUID代表全局唯一标识符

简而言之: (线索就在名字里)

详细: guid被设计为唯一的;它们是使用基于计算机时钟和计算机本身的随机方法计算的，如果你在同一毫秒内在同一台机器上创建多个guid，它们可能是匹配的，但对于几乎所有的正常操作，它们应该被认为是唯一的。

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

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

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

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

http://usecuid.org/

似乎没有人提到它发生概率的实际数学计算。

首先，让我们假设我们可以使用整个128位空间(Guid v4只使用122位)。

我们知道在n次选择中没有得到重复的一般概率是:

(1-1/2128)(1-2/2128)……(1 - (n - 1) / 2128)

因为2128比n大得多，我们可以将其近似为:

(1-1/2128) n (n - 1) / 2

因为我们可以假设n比0大很多很多，我们可以把它近似为:

(1-1/2128) n ^ 2/2

现在我们可以将其等同于“可接受的”概率，假设是1%:

(1-1/2128)n²/2 = 0.01

我们解出n，得到

N =√(2* log 0.01 / log (1-1/2128))

哪个Wolfram Alpha得到5.598318 × 1019

为了更好地理解这个数字，让我们以10000台机器为例，每台机器都有一个4核CPU，工作4Ghz，花费10000个周期来生成一个Guid，其他什么都不做。然后需要大约111年才能产生一个副本。

MSDN:

新Guid的值全为零或等于任何其他Guid的概率非常低。

如果你害怕相同的GUID值，那么把它们放在一起。

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

如果你太多疑，那就放三个。

I think that when people bury their thoughts and fears in statistics, they tend to forget the obvious. If a system is truly random, then the result you are least likely to expect (all ones, say) is equally as likely as any other unexpected value (all zeros, say). Neither fact prevents these occurring in succession, nor within the first pair of samples (even though that would be statistically "truly shocking"). And that's the problem with measuring chance: it ignores criticality (and rotten luck) entirely.

如果真的发生了，结果是什么?你的软件停止工作了吗?有人受伤了吗?有人死了吗?世界会爆炸吗?

临界性越极端，“概率”这个词就越难听。最后，链接guid(或XORing它们，或其他什么)是当你(主观地)认为你的特定临界性(和你的“幸运”感觉)是不可接受的时候所做的事情。如果它能毁灭世界，那么请代表我们所有没有参与大型强子对撞机核试验的人，不要使用guid或任何其他不确定的东西!