要在庞大的数据集上计算复杂的算法，我们希望使用诸如Kafka之类的MQ（或Activemq或AMQP之类的任何其他MQ）来托管两个队列，每个队列分别代表数据集的语义不同部分。消息源自基于两种不同用户角色的Web服务，并将它们放入正确的队列中。
为了实现水平可伸缩性，我们部署了多个工作器来处理队列并计算部分结果，并得出一些总体结果。
为了防止并行计算出现一些问题，我们希望所有工作人员在队列1或队列2上都类似地工作，但不要在它们上混合工作（因为这将需要大量的锁和检查以及额外的db访问权限才能在队列上工作绕圈）。
在队列中，计算顺序不是严格要求的，但值得赞赏。
第一部分：
因此，我们要做的是告诉消息代理从queue1中选择与在线工作人员一样多的消息（假设x），然后让所有工作人员处理（相同的）消息。 ）队列。在确认这些消息已成功处理（我们可能不会丢失消息）之后，代理现在应从queue2中选择x条消息并将其推送给工作程序。
第二部分：
由于queue1通常具有更多消息，因此我们还希望实现一种调度算法以某种方式执行上述操作，以使两个队列的平均大小均匀。基本上，我们可能会重复几次从queue1中进行选择，然后根据比较队列的大小切换到queue2。
第三部分（奖励）：
我们也不确定应该在哪里累积工作人员的结果以将其推送到数据库。该决定将基于ram的使用情况，但是在需要时，服务应位于体系结构中的哪个位置，该体系结构将从DB中获取当前x消息的其他数据，然后将中间结果和最终结果返回给db？ / p>
最后一句话
Kafka或RabbitMQ或任何其他经纪人有可能吗？从体系结构的角度来看，我们的调度程序应该放在哪里？
答案 0 :(得分：0)
复杂的调度规则更适合您的邮件基础结构。
将此调度程序实现为一种服务，可以以交替批处理的方式使用queue1和queue2中的消息，然后将它们重新排队到一个工作队列中，以供您的工作人员使用
此工作队列必须足够长，以使您的工人不会饿死，但必须足够短，以使调度程序可以根据队列长度（第二部分）更改下一个批处理比率。
对于您的最后一个 bonus 部分，尤其是如果最终结果来自此数据的汇总（与每个原始队列任务的一个结果相反），我看不出为什么这些工作人员无法写入结果直接到数据库。
基本上，任何消息代理应该可以实现； RabbitMQ或Kafka绝对可以。