firestore 生成两个相同的随机密钥的机会是多少？

Question

我正在研究一个项目和 firestore 随机键，在这种情况下很重要，所以我的问题是，firebase firestore 或实时数据库生成两个或多个相同随机变量的机会有多大？

Answer 1

根据此博客链接：The 2^120 Ways to Ensure Unique Identifiers

如何生成推送 ID

推送 ID 是在客户端生成的字符串标识符。他们 是时间戳和一些随机位的组合。时间戳 确保它们按时间顺序排列，随机位确保 每个 ID 都是唯一的，即使成千上万的人正在创建推送 同一时间的 ID。

推送 ID 中有什么？

推送 ID 包含 120 位信息。前 48 位是 时间戳，既减少了碰撞的机会，又允许 连续创建推送 ID 以按时间顺序排序。时间戳 后面是 72 位的随机性，这确保了即使两个 在完全相同的毫秒内创建推送 ID 的人非常 不太可能生成相同的 ID。对随机性的一个警告是 为了保持时间顺序，如果客户创建 在同一毫秒内有多个推送 ID，我们只是“增加” 随机位加一。

将我们的 120 位信息（时间戳 + 随机性）转化为 可以用作 Firebase 密钥的 ID，我们基本上是 base64 编码它 转换成 ASCII 字符，但我们使用修改后的 base64 字母表 确保 ID 在订购时仍能正确排序 按字典顺序排列（因为 Firebase 键是按字典顺序排列的）。

Answer 2

虽然 Gastón Saillén 对 Firebase 实时数据库中的推送键的回答是 100% 正确的，但我会尝试添加更多细节。

当使用 DatabaseReference 的 push() 方法时，它会生成一个具有时间分量的密钥，因此理论上两个事件基本上可以在同一毫秒内发生，但是两个用户可以精确生成一个密钥的可能性非常小相同的时刻和完全相同的随机性。另请注意，这些密钥完全在客户端生成，无需咨询 Firebase 服务器。如果你有兴趣，这里是algorithm that generates those keys。最后，我可以告诉你，到目前为止，我还没有听说过有人报告键冲突问题。

因此，与 Fireabase 实时数据库密钥不同，Cloud Firestore id 实际上是完全随机的。不包含时间组件。当您在不传递任何参数的情况下调用 CollectionReference 的 add() 方法或 CollectionReference 的 document() 方法时，Firestore 中使用的唯一 ID 内置生成器会生成随机且高度不可预测的 ID，从而防止命中后端基础架构中的某些热点。如果您在 Firebase 控制台中检查集合中的文档，这也是没有顺序的原因。在这种情况下，id 的冲突是极不可能的，您可以/应该假设它们将是完全唯一的。这就是他们的设计目的。关于算法，您可以从post 查看 Frank van Puffelen 的答案。所以你不必担心这个 id。