基于卡桑德拉的队列是一种反模式。解决方案是什么?

时间:2014-10-20 20:43:29

标签: cassandra queue priority-queue

网上有很多建议说Cassandra在持久可扩展队列方面不是一个好选择,包括来自DataStax的队列:http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets

然而很少有地方提到另一种选择。我想我可能需要一个。

具体来说,我的情景是: 有些任务(比如100多万个)需要在将来的某个时刻执行。因此,每个任务都有一个关联的“runAt”属性,任务需要在“runAt”时间段运行(但允许小延迟)。任务完成后,需要将其从队列中删除。与此同时,新任务以任意速率(比如说100秒/秒或更多)添加到队列中,从现在到1年之间,任意“runAt”值都会被添加到队列中。

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

那么最有意义的是什么?尝试将建议的解决方法调整到使特定问题能够按预期规模工作的程度?或者完全不同的技术更适合这项工作?

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

1 个答案:

答案 0 :(得分:2)

它反模式的原因是因为每次删除都会产生一个墓碑(即数据在压缩之前不会被删除)。此外,分区和后续重新加入宽限期后无需修复可能会导致删除的数据重新出现(例如"僵尸")。根据您的数据速率,总体积,群集大小,用例等,这可能是您愿意做出的权衡。

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