c# - Guid.NewGuid() VS 来自 Random.Next() 的随机字符串生成器

Question

我和我的同事正在讨论使用这些方法中的哪一种来自动生成用户 ID 和帖子 ID 以在数据库中进行识别:

一个选项使用 Random 的单个实例，并采用一些有用的参数，因此它可以重复用于各种字符串生成情况(即从 4 位数字引脚到 20 位字母数字 ID)。这是代码:

// This is created once for the lifetime of the server instance
class RandomStringGenerator
{
    public const string ALPHANUMERIC_CAPS = "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890";
    public const string ALPHA_CAPS = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
    public const string NUMERIC = "1234567890";

    Random rand = new Random();
    public string GetRandomString(int length, params char[] chars)
    {
        string s = "";
        for (int i = 0; i < length; i++)
            s += chars[rand.Next() % chars.Length];

        return s;
    }
}

另一个选项就是简单地使用:

Guid.NewGuid();

见 Guid.NewGuid on MSDN

我们都知道 Guid.NewGuid() 可以满足我们的需要，但我宁愿使用自定义方法。它做同样的事情，但控制更多。

我同事认为因为自定义方法是我们自己炒出来的，所以比较容易产生碰撞。我承认我并不完全了解 Random 的实现，但我认为它与 Guid.NewGuid() 一样随机。自定义方法的典型用法可能是:

RandomStringGenerator stringGen = new RandomStringGenerator();
string id = stringGen.GetRandomString(20, RandomStringGenerator.ALPHANUMERIC_CAPS.ToCharArray());

编辑 1:

• 我们使用的 Azure Tables 没有用于生成 key 的自动递增(或类似)功能。
• 这里的一些答案只是告诉我使用 NewGuid()，“因为它就是为此而生的”。我正在寻找更深入的原因，说明为什么在给定与 Guid 相同的自由度的情况下，精心设计的方法更有可能产生碰撞。

编辑 2:

我们还使用经过精心设计的方法生成帖子 ID，与 session token 不同，它需要看起来漂亮才能在我们网站的 url 中显示(如 http://mywebsite.com/14983336 )，因此 guid 在这里不是一个选项，但是冲突仍然存在避免。

Answer 1

I am looking for a more in depth reason as to why the cooked up method may be more likely to generate collisions given the same degrees of freedom as a Guid.

首先，正如其他人所指出的，Random 不是线程安全的；从多个线程使用它会导致它破坏其内部数据结构，从而始终生成相同的序列。

其次，Random 是根据当前时间播种的。在同一毫秒内创建的两个 Random 实例(回想一下，在现代硬件上，一毫秒是几 百万 个处理器周期)将具有相同的种子，因此会产生相同的序列.

第三，我撒谎了。 Random 不根据当前时间播种；它是根据机器处于事件状态的时间来播种的。种子是一个 32 位数字，并且由于粒度以毫秒为单位，因此只有几周的时间才能完成。但这不是问题；问题是:您创建 Random 实例的时间段很可能在机器启动后的几分钟内。 每次重启一台机器，或者在集群中将一台新机器联机，会有一个小窗口，其中会创建 Random 实例，发生的次数越多，您获得之前拥有的种子的可能性就越大。

(更新:较新版本的 .NET 框架已经缓解了其中的一些问题；在那些版本中，您不再让在同一毫秒内创建的每个 Random 都具有相同的种子。但是仍然有Random 有很多问题；永远记住它只是伪随机，而不是加密强度随机。Random 实际上是非常可预测的，所以如果你依赖于不可预测性，它不合适。)

正如其他人所说:如果您想要数据库的主键，那么让数据库为您生成一个主键；让数据库完成它的工作。如果你想要一个全局唯一的标识符，那么使用 guid；这就是他们的目的。

最后，如果您有兴趣了解更多有关 guid 的使用和滥用的信息，那么您可能想阅读我的“guid 指南”系列；第一部分在这里:

https://ericlippert.com/2012/04/24/guid-guide-part-one/