基于 Cassandra 的队列是一种反模式。解决方案是什么？

Question

网络上有很多建议，当涉及到持久可扩展队列时，Cassandra 不是一个好的选择，包括来自 DataStax 的这个：http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets

但很少有地方提到替代方案。我想我可能需要一个。

具体来说，我的情况是： 未来的某个时间点需要执行一些任务（假设有 100+ 数百万个）。因此，每个任务都有一个关联的“runAt”属性，并且任务需要在其“runAt”时间经过时运行（但允许有小的延迟）。随着任务完成，它们需要从队列中移除。同时，从现在到 1 年后，新任务以任意“runAt”值以任意速率（比如 100 秒/秒或更高）添加到队列中。

一个可能的实现将利用 Cassandra 对行中的列进行排序的能力，并使用读取/删除技术的一些变体（即读取队列顶部，执行任务并将它们从队列中删除） queue)，它与上面提到的反模式非常相似。

那么什么最有意义？尝试将建议的解决方法调整到可以使这个特定问题在预期规模下工作的程度？还是完全不同的技术更适合这项工作？

任何帮助/建议将不胜感激。

Answer 1

它是反模式的原因是因为每次删除都会导致墓碑（即数据在压缩之前不会被删除）。此外，在没有修复的宽限期之后分区和后续重新加入可能会导致已删除的数据重新出现（例如“僵尸”）。根据您的数据速率、总容量、集群大小、用例等，这可能是您愿意做出的权衡。

如果没有，可能看看一些协调工具会更有意义。也许 Zookeeper 可以在这里使用。