我一直在研究如何有效地解决以下用例,我正在努力寻找最佳解决方案。
基本上,我有一个Node.js REST API,它处理来自移动的应用程序的用户请求。我们希望一些请求在req/res流之外启动后台任务,因为它们是CPU密集型的,或者可能只是需要一段时间来执行。我们正在尝试实现或使用任何现有的框架,这些框架能够以下面的方式处理不同的作业队列(或者至少与用例兼容):
- 每个用户都有自己的一组作业队列(有不同种类的作业)。
- 一个特定队列中的作业必须按顺序执行,并且一次只能执行一个作业,但其他所有作业都可以并行执行(最好没有队列占用工作线程或实际消耗任务的任何东西,以便所有队列获得或多或少相同的优先级)。
- 某些队列在给定时间可能会填满数百个任务,但很可能在很多时间都是空的。
- 队列需要是持久的。
我们目前有一个RabbitMQ的解决方案,所有用户共享的每种任务都有一个队列。用户将任务转储到相同的队列中,这会导致它们长时间被来自特定用户的任务填满,而其他用户则要等待这些任务完成后才开始使用自己的任务。我们已经研究过优先级队列,但我们不认为"这是我们自己的用例应该走的路。
我们想到的第一个合乎逻辑的解决方案是,每当用户需要运行后台作业时创建临时队列,并在队列为空时将其删除。然而,我们不确定拥有这么多队列是否可扩展,而且我们还在努力动态创建RabbitMQ队列、交换等(我们甚至在某处读到过,这可能是一个反模式?)
我们一直在做一些更多的研究,也许要走的路将与其他的东西,如Kafka或基于Redis的东西,如BullMQ或类似的。
您有什么建议吗?
2条答案
按热度按时间flvlnr441#
如果你使用AWS,你考虑过SQS吗?它对创建的标准队列数量没有限制,传输中的消息可以达到120k。这似乎可以满足你的上述要求。
d4so4syb2#
虽然前面提到的SQS解决方案确实证明了我们需要进行的大量轮询非常具有可扩展性,但是SNS的使用并没有使解决方案达到最佳。另一方面,通过数据库轮询实现一个自制的解决方案对于我们的用例来说太多了,我们没有时间或计算资源来考虑堆栈中的另一个新数据库。
幸运的是,我们最终发现BullMQ的Pro版本确实有一个“Group“功能,它在一个队列中为不同的任务执行循环策略。这最终完美地调整到了我们的用例,也是我们最终使用的。