ASP Core自定义唯一ID：碰撞安全性与缩短方案咨询

我在MySQL的ASP Core数据库中存储用户数据，需通过QR Code将用户与实体卡关联。除ASP Core自动生成的Id外，我自定义了格式为「32位随机字母数字字符.Unix Timestamp」的ID，以便实体卡失效或丢失时重新生成。相关C#代码如下：

public static string GenerateSecureUniqueId()
{
    return $"{GenerateRandomString(32)}.{GenerateDateTimeHash(DateTime.Now)}";
}

private const string AlphanumericChars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";

public static string GenerateRandomString(int length)
{
    var sb = new StringBuilder(length);

    for (int i = 0; i < length; i++)
    {
        int index = Random.Next(AlphanumericChars.Length);
        sb.Append(AlphanumericChars[index]);
    }

    return sb.ToString();
}


private static long ConvertToUnixTimestamp(DateTime dateTime)
{
    return ((DateTimeOffset)dateTime).ToUnixTimeMilliseconds();
}

public static string GenerateDateTimeHash(DateTime dateTime)
{
    byte[] dateTimeBytes = BitConverter.GetBytes(ConvertToUnixTimestamp(dateTime));
    return ByteArrayToHexString(dateTimeBytes);
}

现有疑问：

• 该ID生成方案是否能避免碰撞？
• 能否进一步缩短ID长度以优化QR Code打印效果？
  需支持500K+用户及Chats、Metadata等其他数据表的ID生成，确保无碰撞风险。

碰撞风险分析与改进建议 #

当前方案的碰撞可能性 #

• 32位字母数字字符的组合数为62^32（约1.8×10^57），这个量级远大于500K+用户及其他数据表的总需求，理论上碰撞概率无限接近于0。
• 但代码中使用的Random类并非加密安全的随机数生成器，在高并发场景下可能出现重复的随机序列，存在极小的碰撞隐患。
• 附加的毫秒级Unix时间戳进一步降低了碰撞概率，但如果同一毫秒内生成大量ID，时间戳无法区分，此时仍依赖随机字符串的唯一性。

确保无碰撞的改进措施 #

• 将Random替换为RandomNumberGenerator（加密安全的随机数生成器），避免高并发下的随机序列重复问题，示例代码如下：

  public static string GenerateRandomString(int length)
  {
      var sb = new StringBuilder(length);
      var randomBytes = new byte[length];
      using (var rng = RandomNumberGenerator.Create())
      {
          rng.GetBytes(randomBytes);
          foreach (byte b in randomBytes)
          {
              sb.Append(AlphanumericChars[b % AlphanumericChars.Length]);
          }
      }
      return sb.ToString();
  }
  

• 在数据库中给自定义ID字段添加唯一约束，即使极端情况出现碰撞，数据库会直接拒绝插入，从底层保证数据一致性。

ID长度优化方案（适配QR Code） #

当前ID总长度为49位（32位随机串 + 1位分隔符 + 16位十六进制毫秒时间戳），可通过以下方式大幅缩短：

1. 优化时间戳表示 #

• 无需将毫秒时间戳转十六进制，直接使用十进制字符串，长度为13位（当前毫秒级时间戳是13位数字），比原来的16位十六进制减少3位。
• 若业务允许秒级精度，时间戳可缩短至10位，再减少3位，但需注意同一秒内生成大量ID的场景。

2. 缩减随机串长度（基于需求匹配熵值） #

根据生日悖论，针对1.5×10^{6的总ID量（500K用户+其他数据表），若要保证碰撞概率低于10}-12，仅需约81比特的熵：

• 62进制字符（当前使用的字母数字）每字符约5.95比特熵，因此仅需14位随机串即可满足需求（14×5.95≈83.3比特），比原来的32位减少18位。

3. 移除分隔符 #

将随机串与时间戳直接拼接，程序解析时可通过固定长度区分（比如前14位为随机串，后13位为时间戳），减少1位分隔符。

4. 综合优化后的效果 #

优化后ID总长度为27位（14位随机串 + 13位十进制毫秒时间戳），仅为原长度的55%，完全适配QR Code的打印需求，同时碰撞概率可忽略不计。

内容的提问来源于stack exchange，提问作者Epic Gamer