使用票务服务器生成主 ID？答案

【问题标题】：Using a ticket server to generate primary ids?使用票务服务器生成主 ID？
【发布时间】：2011-07-05 21:58:58
【问题描述】：

我正在 Java 和 Cassandra 之上构建一个分布式应用程序。要生成唯一的顺序 32 位和 64 位 ID，使用Flickr's ticket servers 生成主 ID 之类的方法是一种好方法吗？我对此感到特别兴奋，因为它可以帮助我根据需要将 ID 的大小减少到 32 位或 64 位，否则 UUID 可能会增加到 128 位。我不希望这些 ID 完全连续，但至少会增加！

但是，使用单个数据库服务器可能会引入 Cassandra 消除的单点故障。但是，这对于我们应用程序的初始阶段可能是可以的。稍后我们可能会引入两台服务器来缓解这些问题。

这听起来是个好策略吗？简而言之，我们将 MYSQL 和 Cassandra 混合在一个应用程序中。我知道，如果 mySQL 由于某种原因出现故障，那么我们无法单独使用 Cassandra。

我们已经寻找过像雪花这样的其他解决方案，但它并不完全符合我们的要求。

编辑：我正在寻求有关使用 MySQL 生成唯一主 ID 来键入存储在 Cassandra 数据库中的数据/实体的建议是否是一种好方法。像 Flickr 的票务服务器这样的方法有什么缺点（如果有的话）？

【问题讨论】：

我认为这里有一个问题，但很难确切地看到你在问什么。请澄清
骗子：stackoverflow.com/questions/3935915/…（但无解，仅供参考）
我检查过了.. 但没有用，因为没有答案
引入单点故障确实破坏了分布式系统的主要优势。那么你的要求是什么？为什么雪花不匹配他们？为什么 ID 的顺序很重要？
我需要生成 32 位和 64 位的 ID，它们按升序大致排序。我还想要一些空闲位（在 64 位 ID 中大约 4 个）根据数据类别将单个实体的数据分成两行。我会在 Id 的末尾附加一些额外的位，因此需要一些空闲位。

标签： java mysql web-applications primary-key

【解决方案1】：

我不太喜欢尝试将含义附加到代理键（如果您希望它们随着时间的推移而增加，您会尝试这样做）。如您所见，它使您生成密钥的问题更加复杂。假设您希望密钥随着时间的推移而增加以便您可以对数据进行排序，为什么不包括对象创建时间的时间戳并将其存储在数据存储中呢？这显着简化了密钥的生成，并允许您使用随时间增加的密钥做几乎所有可以做的事情，另外一个好处是，对于需要维护您的代码的任何人来说，对象应该如何排序是非常清楚的。

【讨论】：

我要补充一点，在您的密钥中插入一些有意义的数据也是如此 - 为什么不为这些有意义的数据设置单独的字段？

【解决方案2】：

一般来说，您不能同时拥有“始终增加”和“没有 SPOF 和没有复杂同步”。

如果您希望有多个 ID 生成器不必在每个新 ID 上相互询问，那么它们中的每一个都需要一个单独的 ID 池。

您链接的文章中提到了一个非常简单的示例，其中一台服务器创建奇数，而另一台服务器创建偶数。（您可以轻松地将其扩展到更多服务器）。当然，那么你不能确定一个服务器不会先于另一个运行，这可能会导致序列不递增，例如 111、120、113、122、115、124 ...

如果您只想“粗略增加”，您可以实施一种方案，其中每个服务器以一定的时间间隔（例如每分钟或每 10000 个 ID）告诉其他服务器他当前的 ID，然后另一个服务器跳过它的如果他后退太远，则拥有自己的 ID（仅向前）。这应该以不中断 ID 生成的方式完成，以便在其他服务器关闭时保持稳健性。

啊，对于“末尾的空闲位”，只需将您的 ID 乘以 number（每次相同，如果您真的想要“空闲位”而不仅仅是“空间数据”），然后添加您的数据（应小于number）。但是当然，您会在很早之前就用完 ID 空间（因数 number）。

【讨论】：