UUID 的紧凑替代品作为相关 ID

Question

我正在向我们的公共和私有 API 添加相关 ID。这是为了能够通过日志跟踪请求进度。 UUID 是长字符串，占用大量空间。我需要一个紧凑的替代 UUID 作为相关 ID。

如果相关 ID 在修复期（比如 2 个月）后重复出现，那没关系，因为不再需要跟踪比这更早的 API 请求。

我考虑过使用java.util.Random nextLong()。但不保证不会重复。

此外，SecureRandom 可能会造成一些性能问题，这是我的理解，而且我不需要相关 ID 是安全的。

最好考虑其他选项。

Answer 1

如果您可以接受最多 8 个字符的 ID，则可能的 ID 数量取决于这些 ID 的字符集。

• 对于十六进制字符（16 个字符集），ID 的数量为 4294967296 或 2^32。
• 对于 A-Z、0-9（36 个字符集），ID 的数量为 2821109907456 或大约 2^41。
• 对于 base64 或 base64url，0-9（63 个字符集），ID 的数量为 248155780267521 或大约 2^47。

您应该决定使用哪个字符集，并问问自己您的应用程序是否可以检查 ID 的随机性以及您是否可以容忍重复 ID 的风险（这样您就不会遇到使用 @ 随机生成它们的问题987654323@)。还要注意以下几点：

• 重复的风险取决于可能的 ID 数量。粗略地说，在您的应用程序随机生成所有可能 ID 的平方根之后，重复的风险变得不可忽略（在十六进制 ID 的情况下，将在 65536 个 ID 之后发生）。请参阅“Birthday problem”了解更精确的语句和公式。
• 如果您的应用程序分布在多台计算机上，您可以选择为每台计算机分配一个唯一值以包含在 ID 中。
• 如果您不关心相关 ID 是否安全，您可以选择通过对顺序 ID 执行可逆操作（例如可逆混合函数或线性同余生成器）来创建唯一 ID。
• 你说SecureRandom“会造成一些性能问题”。除非您尝试并衡量您的应用程序的性能，否则您不会知道它是否会。使用SecureRandom 生成 ID 对于您的目的而言可能会也可能不会太慢​​。

有关进一步的考虑和建议，请参阅我在“Unique Random Identifiers”上写的内容。