我正在Java和Cassandra之上构建分布式应用程序。生成独特的顺序32位＆amp; 64位ID，是一种使用Flickr's ticket servers生成主ID的方法，一个好的方法？我对此特别感到兴奋，因为它可以帮助我根据需要将ID的大小减小到32位或64位，否则可能会使用UUID将其减少到128位。我不希望这些ID完全顺序，但至少增加！
然而，使用单个数据库服务器可能会引入Cassandra消除的单点故障。但是，对于我们的应用程序的初始阶段，这可能没问题。稍后我们可能会引入两台服务器来缓解这些问题。
这听起来像是一个好策略吗？简而言之，我们将MYSQL和Cassandra混合在一个应用程序中。我知道，如果mySQL由于某种原因而失效，那么我们就无法单独使用Cassandra。
我们已经研究过雪花等其他解决方案，但它并不完全符合我们的要求。
编辑：我正在寻求关于使用MySQL生成唯一主ID以密钥存储在Cassandra数据库中的数据/实体是一种好方法的建议。像Flickr的票务服务器这样的方法有哪些缺点？
答案 0 :(得分：3)
我不是试图为代理键添加意义的忠实粉丝（如果你希望它们随着时间的推移而增加，那么你试图这样做）。正如您所看到的，它使您生成密钥的问题变得更加复杂。假设您希望密钥随着时间的推移而增加，以便您可以对数据进行排序，为什么不包括创建对象的时间戳并将其存储在数据存储中？这大大简化了密钥生成，并且允许您使用随时间增加的密钥完成所有可以做的事情，并且对于任何必须维护代码如何对对象进行分类的事实都会非常清楚。< / p>
答案 1 :(得分：1)
一般情况下，你不能同时“总是增加”和“没有SPOF而且没有复杂的同步”。
如果你想拥有几个不必在每个新ID上相互询问的ID生成器，那么每个ID生成器都需要一个单独的ID池。
在您链接的文章中提到了一个非常简单的示例，其中一个服务器创建奇数，而另一个创建偶数。 （您可以轻松地将其扩展到更多服务器）。当然，那么你不能确定一台服务器没有在另一台服务器之前运行，这可能导致不增加的序列，如111,120,113,122,115,124 ......
如果你只想“粗略增加”，你可以实现一个方案，其中每个服务器在某些时间间隔（如每分钟或每个10000个ID）告诉另一个服务器他当前的ID，然后另一个服务器跳转其如果他挂得太远，他自己的身份证（只有前锋）。这应该以不中断ID生成的方式完成，以便在其他服务器关闭时具有健壮性。
啊，对于“末尾的免费比特”，只需将你的ID乘以number（每次都是相同的，如果你真的想要“免费比特”而不仅仅是“数据空间“），然后添加您的数据（应该小于number）。但是当然，你会早点用完ID空间（按因子number）。