我阅读了很多Cassandras文档并检查了Counter的变化等。但它的接缝是Cassandra没有提供默认和标准的方式来动态生成增量序列。
我发现只是通过比较和设置来使用IF语句/子句。
这样可以检查文档是否存在，如果不存在则生成文档。由于这是通过一个被视为群集的仲裁算法来完成的，因此它应该易于使用且安全但具有高延迟。
为了避免这种延迟，可以通过将nextSequenceId增加千而不是一来生成（保留）一千个ID。这种方式只有在生成千位中的第一个时才支付延迟（或者如果它过早地完成它将几乎没有延迟）。
我知道这样做会造成热点或拥挤。
避免这种拥塞的一种方法是使用更多的序列号生成器，所有生成器都通过不同的偏移量（模数）并通过选择模数随机选择某个序列生成器来限制冲突的可能性。
所以这将是我天真的实施。
自从Cassandra 3.0上街以来，我只想知道三件事：
答案 0 :(得分：2)
Jonathan为这个主题开了一个Jira - https://issues.apache.org/jira/browse/CASSANDRA-9200
3.0还没有结束，但似乎提交者正在最终确定3.0的功能，并且似乎为3.1设置了9200（这实际上意味着＆＃34;在3.0和＃34之后的某个时间; - 可能是3.1 ，也许是3.2，也许是4.0）。
对于你的问题：
1）不，此时没有内置的方法在cassandra中进行排序
2）不，如果您能够容忍不严格增加的序列，您将不得不进行先读后读取或阻止每个节点的序列部分
3）Twitter一度发布了Snowflake（https://github.com/twitter/snowflake），但它现在已经退休了。通常，我倾向于使用类型1 UUID，它是基于随机组件的时间戳。即使是UUID也不是万无一失的，但对于我们的工作量来说，它们往往足够好。＆＃39; Simpleflake（http://engineering.custommade.com/simpleflake-distributed-id-generation-for-the-lazy/）讨论了我提供的链接的权衡，并提供了自己的生成器。