Flake ID 和加密 ID 的优缺点
Pros and cons of Flake ids and cryptographic Ids
分布式系统可以通过 Flake 或加密 ID（例如 128 位 murmur3）生成唯一 ID。
想知道每种方法的优缺点是什么。
我将假定 128 位 ID，类似于 UUID。不过，让我们从基线开始吧
TL;DR：使用随机 ID。如果并且仅当您遇到数据库性能问题时，请尝试薄片 ID。
自动递增 ID
自动递增 ID 是指您的后端系统为每个新实体分配一个唯一的、密集打包的 ID。这通常由数据库完成，但并非总是如此。
明显的优势是 id 保证对您的系统是唯一的，尽管 128 位可能有点过分了。
第一个缺点就是每次暴露id都会泄露信息。您泄露了其他 ID（攻击者可以轻松猜出要查找的内容）。您还泄露了系统的繁忙程度（您的竞争对手现在知道您在一段时间内创建了多少个 ID，并且可以推断出财务信息）。
第二个缺点是您的后端不再具有可扩展性。您受制于一些速度慢、可扩展性差的 ID 生成器，这将始终成为大型系统中的瓶颈。
随机 ID
Random ids 是当你只生成 128 个随机字节时。 v4 UUID 122 位随机 ID（例如 2bbfb5ba-f5a2-11e7-8c3f-9a214cf093ae）。这些实际上也是独一无二的。
随机 ID 摆脱了自动递增 ID 的两个缺点：它们不泄漏任何信息并且可以无限扩展。
在 b 树（如数据库）中存储 id 时会出现缺点，因为它们会随机化树访问的 memory/disk 页面。这可能 是导致您的系统变慢的原因。
对我来说，这仍然是理想的 ID 方案，您应该有充分的理由放弃它。 （即探查器数据）。
薄片 ID
Flake ids 是随机 ids，除了高 k 位取自时间戳的低位。例如，你可能会连续得到以下三个id，其中前几位非常接近。
- 2bbfb5baf5a211e78c3f9a214cf093ae
- 2bbf9d4ec10c41049fb1671d6616b213
- 2bc6bb66e5964fb59050fcf3beed51b1
虽然您可能会泄露一些信息，但如果您的 k 和时间戳粒度设计得当，就不会泄露太多。
但是，如果你错误地设计了 id，它们可能就没有什么用了，要么更新太少——导致 b 树依赖于顶部的随机位而否定了有用性——或者太频繁——你会在那里颠簸数据库因为你的更新。
注意：时间粒度是指时间戳的低位更改的频率。根据您的数据吞吐量，您可能希望它是小时、十分钟或分钟。这是一个平衡。
如果您看到 id 没有其他语义（即永远不会从最高位推断出任何内容），那么您可以随时更改这些参数中的任何一个而不会中断——甚至可以回到纯随机 k = 0 .
加密 ID
我假设你的意思是 id 中有一些加密的语义信息。也许喜欢 hashids?
缺点比比皆是：
- 除非您有固定长度的协议，否则您将对不同的数据使用不同长度的 ID。
- 您会忍不住向 ID 添加越来越多的信息。
- 看起来是随机的，但没有任何缓解措施可以在前面添加片状时间戳
- ID 与创建它的系统相关联。您可能会开始向该系统询问 id 的解密版本，而不仅仅是询问它指向的数据。
- 您的系统在解密 ID 以提取数据时会消耗大量时间。
- 你添加加密问题
- 如果秘钥泄露了怎么办？ （最好不要有太敏感的数据，客户姓名，或者信用卡号）
- 协调密钥轮换。
- 像 hashid 这样的小 ID 可以被暴力破解。
如您所见，我一般不喜欢语义 ID。我在一些地方使用它们，尽管我称它们为 tokens。这些不会作为 keys 存储在数据库中（或者可能不会存储在任何地方）。
例如，我对分页令牌使用加密：分页 API 的加密 {last-id / context}。我更喜欢这个而不是让客户端传递前一页的最后一个元素，因为我们对用户隐藏了数据库上下文。它对每个人来说都更简单，而且加密只是混淆（没有敏感信息）。
分布式系统可以通过 Flake 或加密 ID（例如 128 位 murmur3）生成唯一 ID。
想知道每种方法的优缺点是什么。
我将假定 128 位 ID，类似于 UUID。不过，让我们从基线开始吧
TL;DR：使用随机 ID。如果并且仅当您遇到数据库性能问题时，请尝试薄片 ID。
自动递增 ID
自动递增 ID 是指您的后端系统为每个新实体分配一个唯一的、密集打包的 ID。这通常由数据库完成，但并非总是如此。
明显的优势是 id 保证对您的系统是唯一的，尽管 128 位可能有点过分了。
第一个缺点就是每次暴露id都会泄露信息。您泄露了其他 ID（攻击者可以轻松猜出要查找的内容）。您还泄露了系统的繁忙程度（您的竞争对手现在知道您在一段时间内创建了多少个 ID，并且可以推断出财务信息）。
第二个缺点是您的后端不再具有可扩展性。您受制于一些速度慢、可扩展性差的 ID 生成器，这将始终成为大型系统中的瓶颈。
随机 ID
Random ids 是当你只生成 128 个随机字节时。 v4 UUID 122 位随机 ID（例如 2bbfb5ba-f5a2-11e7-8c3f-9a214cf093ae）。这些实际上也是独一无二的。
随机 ID 摆脱了自动递增 ID 的两个缺点：它们不泄漏任何信息并且可以无限扩展。
在 b 树（如数据库）中存储 id 时会出现缺点，因为它们会随机化树访问的 memory/disk 页面。这可能 是导致您的系统变慢的原因。
对我来说，这仍然是理想的 ID 方案，您应该有充分的理由放弃它。 （即探查器数据）。
薄片 ID
Flake ids 是随机 ids，除了高 k 位取自时间戳的低位。例如，你可能会连续得到以下三个id，其中前几位非常接近。
- 2bbfb5baf5a211e78c3f9a214cf093ae
- 2bbf9d4ec10c41049fb1671d6616b213
- 2bc6bb66e5964fb59050fcf3beed51b1
虽然您可能会泄露一些信息，但如果您的 k 和时间戳粒度设计得当，就不会泄露太多。
但是，如果你错误地设计了 id，它们可能就没有什么用了，要么更新太少——导致 b 树依赖于顶部的随机位而否定了有用性——或者太频繁——你会在那里颠簸数据库因为你的更新。
注意：时间粒度是指时间戳的低位更改的频率。根据您的数据吞吐量，您可能希望它是小时、十分钟或分钟。这是一个平衡。
如果您看到 id 没有其他语义（即永远不会从最高位推断出任何内容），那么您可以随时更改这些参数中的任何一个而不会中断——甚至可以回到纯随机 k = 0 .
加密 ID
我假设你的意思是 id 中有一些加密的语义信息。也许喜欢 hashids?
缺点比比皆是：
- 除非您有固定长度的协议，否则您将对不同的数据使用不同长度的 ID。
- 您会忍不住向 ID 添加越来越多的信息。
- 看起来是随机的，但没有任何缓解措施可以在前面添加片状时间戳
- ID 与创建它的系统相关联。您可能会开始向该系统询问 id 的解密版本，而不仅仅是询问它指向的数据。
- 您的系统在解密 ID 以提取数据时会消耗大量时间。
- 你添加加密问题
- 如果秘钥泄露了怎么办？ （最好不要有太敏感的数据，客户姓名，或者信用卡号）
- 协调密钥轮换。
- 像 hashid 这样的小 ID 可以被暴力破解。
如您所见，我一般不喜欢语义 ID。我在一些地方使用它们，尽管我称它们为 tokens。这些不会作为 keys 存储在数据库中（或者可能不会存储在任何地方）。
例如，我对分页令牌使用加密：分页 API 的加密 {last-id / context}。我更喜欢这个而不是让客户端传递前一页的最后一个元素，因为我们对用户隐藏了数据库上下文。它对每个人来说都更简单，而且加密只是混淆（没有敏感信息）。