2016-09-27 49 views
1

我建立一个多租户应用程序,用户可以提交至工(工人数量是动态的)来处理的任务批我想要实现的是以下几点:共享工人的池RabbitMQ的

  • 如果我们从一个用户单批次,已全部工人的信息工作从这个单个用户
  • 如果另一个用户提交批作业,每个用户得到一半的工人(以使第一用户现在以较慢的速度工作,而后来用户不必等到第一个用户已经完成了所有的工作冗长)

这样的事情可能与工作队列? (出于某种原因,感觉就像一个转折FIFO和队列的想法,但是这是我的用例不管怎么说:d)

回答

0

你可以看一下优先级队列实现:https://www.rabbitmq.com/priority.html

如果还是不行为你工作,你可以尝试一些其他的黑客实现你想要的:

你可以有100个队列绑定到话题交换,并将路由关键字设置为用户ID%100的散列,即每个任务将有1到100之间的键和同一用户的任务将具有相同的键。每个队列与1和100之间的独特图案的结合现在你有一个随机队列号开始的工人组成的机队,然后每增加作业后该队列数量,再100%可循环回到队列100后,排队1。现在

你的工人舰队能够并行处理多达100个独特的用户,或者所有的工人可以专注于一个单一的用户,如果没有其他的工作要做。如果工作人员需要在每个作业之间遍历所有100个队列,在单个用户在单个队列中只有很多作业的情况下,每个作业之间自然会产生一些开销。少量的队列是解决这个问题的方法之一。您也可以让每个工作人员与每个队列保持连接,并使用每个队列最多一个未确认的消息。只要未确认的消息超时设置得足够高,工作人员就可以更快地循环访问内存中的待处理消息。

另外,您可以创建两个交易所,每一个绑定的队列。所有的工作都进入第一次交换和排队,这是一群工人消耗的。如果一个工作单元花费太长时间,工作人员可以取消它并将其推送到第二个队列。当第一个队列中没有任何内容时,工作人员只处理第二个队列。您可能还需要一些具有相反队列优先级的工作人员,以确保在存在永不停止的短任务流时仍处理长时间运行的任务,以便最终始终处理用户批处理。这不会真正将工作人员分配到所有任务中,但它将阻止持有员工的长期运行任务,从而不会为同一用户执行短期运行任务。它还假定您可以取消一项工作,稍后重新运行而不会出现任何问题。这也意味着将会出现超时并需要重新运行为低优先级任务的资源浪费。除非你能提前

识别快,慢任务,并具有100个队列第一个建议也可能有问题,如果有单个用户100级慢的任务,然后另一个用户的帖子一批任务。直到其中一项缓慢的任务完成后,才会查看这些任务。如果事实证明这是一个合理的问题,你可以结合这两种解决方案。