目前，我们有一定数量的发布者（微服务）发布其消息以进行交换。每个消息都有一个serviceId属性。队列连接到处理队列消息的单个订户（微服务），处理单个消息是一项昂贵的操作（大约需要20到30秒）。 当前，我们处于以下情况：服务A发布约200条消息，几秒钟后服务B发布2条消息。因此，只有在处理前200条消息后，订阅者才会处理这2条消息。
我们要按照到达队列的顺序处理消息，但要针对源serviceId。
一种明显的解决方案是将队列划分为一个单独的队列（每个发布者一个）并分别订阅每个队列，但是发布者的数量可以更改，我们需要动态地请求它们并订阅（取消订阅）。
另一种方法是复制我们的订户应用，以在发布者和订户之间建立一对一的关系，但这将需要更多的系统资源。
处理这种情况的最佳方法是什么？ 谢谢！
答案 0 :(得分：0)
/！\注意，发布者发布到交换而不是队列。
我们要按照消息进入队列的顺序进行处理， 但关于源serviceId。
据我所知，您想根据serviceId对消息进行负载平衡，而serviceIds事先未知。
我在这里建议的解决方案是使用诸如xxxxx.<serviceId>之类的路由密钥进行直接交换。然后，您可以按serviceId绑定一个队列（即：一个队列用于服务A，一个队列用于服务B，...），每个使用者在所有队列上消耗。
然后，您必须处理发布者订阅：我将使发布者发布“ hello”消息，该消息由每个使用者使用，然后依次为该服务绑定新队列（使用xxxxx.<newServiceId>） ，最后发布回响应（以便发布者可以开始发送消息）。
注意：所有使用者的每个服务队列都是相同的，从而导致工作器配置（请参见this tutorial）
希望这会有所帮助。