片状ID和加密ID的优缺点

Question

分布式系统可以通过Flake或加密ID（例如，128位murmur3）生成唯一ID。

想知道每种方法的优缺点是什么。

Answer 1

我将假设128位ID，类似UUID。让我们从基线开始，但

TL; DR ：使用随机ID。如果和只有你有数据库性能问题，请尝试使用flake id。

自动增加ID

自动增量ID是指您的后端系统为每个新实体分配唯一且密集的ID。这通常由数据库完成，但并非总是如此。

明显的优势是，系统保证id是唯一的，尽管128位可能有点过分。

第一个缺点是每次暴露您的ID时都会泄漏信息。你泄漏了其他的id（攻击者很容易猜到要查找的内容）。您还泄漏了系统的繁忙程度（您的竞争对手现在知道您在一段时间内创建了多少ID，并且可以推断出财务信息）。

第二个缺点是你的后端不再具有可扩展性。你被绑定到一个缓慢，不太可扩展的id生成器，它永远是大型系统的瓶颈。

随机ID

随机ID是指您只生成128个随机字节。 v4 UUID 122 位随机ID（例如2bbfb5ba-f5a2-11e7-8c3f-9a214cf093ae）。这些也几乎是独一无二的。

随机ID摆脱了自动增量ID的两个缺点：它们不泄漏任何信息，并且可以无限扩展。

将id存储在b-trees（数据库）中时会产生缺点，因为它们随机化了树访问的内存/磁盘页面。 可能成为系统减速的源头。

对我而言，这仍然是理想的身份识别方案，你应该有充分的理由离开它。 （即剖析数据）。

片状ids

片状ID是随机ID，除了高k位取自时间戳的低位。例如，您可以连续获得以下三个ID，其中顶部位非常靠近。

1. 的 2BB fb5baf5a211e78c3f9a214cf093ae
2. 的 2BB f9d4ec10c41049fb1671d6616b213
3. 的 2BC 6bb66e5964fb59050fcf3beed51b1

虽然您可能会泄漏某些信息，但如果您的k和时间戳粒度设计得很好，则不会太多。

但是，如果你对这些ID进行错误设计，它们可能不那么有用，或者很少更新 - 导致b-tree依赖顶部随机位来否定有用性 - 或者太频繁 - 你在哪里捶打数据库因为你的更新。

注意：按时间粒度，我的意思是时间戳的低位变化的频率。根据您的数据吞吐量，您可能希望将其设置为小时，十分钟或分钟。这是一个平衡。

如果您看到其他语义较少的ID（即从不从顶部位推断出任何内容），那么您可以随时更改这些参数中的任何一个而不会中断 - 甚至可以返回到k = 0的纯粹随机。 / p>

密码ids

我假设你的意思是ids在其中加密了一些语义信息。也许像hashids？

缺点比比皆是：

• 除非您拥有固定长度的协议，否则您将拥有不同数据的长度ID。
• 您会想要向ID添加越来越多的信息。
• 看起来是随机的，但没有任何缓解措施可以在前面添加类似时间戳的时间戳
• Ids与制造它的系统联系在一起。您可以开始向该系统询问id的解密版本，而不是只询问它指向的数据。
• 您的系统会耗费时间解密ID以提取数据。
• 您添加了加密问题
  • 如果秘密密钥被泄露会怎样？ （最好不要对那里的数据过于敏感，客户名称或天堂禁止信用卡号码）
  • 协调密钥轮换。
  • 像hashid这样的小ids可能是强暴攻击。

正如您所看到的，我一般不喜欢语义ID。有几个地方我使用它们，虽然我称之为令牌。这些不会作为 keys 存储在数据库中（或者可能不存储在任何地方）。

例如，我对分页令牌使用加密：加密{last-id / context}分页API。我更喜欢这个让客户端传递前一页的最后一个元素，因为我们保持数据库上下文对用户隐藏。它对每个人来说都比较简单，加密只不过是混淆（没有敏感信息）。