队列消息中的类型属性是不是表明 RabbitMQ 设计不佳？

Posted 2023-02-19

【中文标题】队列消息中的类型属性是不是表明 RabbitMQ 设计不佳？

【英文标题】：Is having a type property in a queue message an indication of a bad design in RabbitMQ?队列消息中的类型属性是否表明 RabbitMQ 设计不佳？

【发布时间】：2022-01-19 23:48:24

【问题描述】：

我试图更好地理解使用一般队列特别是 RabbitMQ 设计分布式系统的细微差别。

假设我有类似的消息

  "id": 12,
  "name": “John”
  "role": “Employee”

和

  "id": 13,
  "name": “Alex”,
  "role": “Manager”,
  "level": 1

注意 role 属性。

当每个人完成对文档的签名后，发布者将发送上述消息。消费者应该根据个人的角色做不同的事情。

设计方法

消息是否应该进入直接交换（没有路由键）并最终进入1队列？消费者需要收听一个队列，因此它有责任识别演员的哪种类型（基于角色）签署了一份文档。

消息是否应该进入直接交换（使用路由键）并最终进入2个不同的队列？发布者可以使用 2 个不同的路由键发布消息。 RabitMQ 可以处理路由。消费者将收听 2 个不同的队列。这种方法无需在消息中使用角色属性。

这是否应该转到主题交换（使用路由密钥）并最终转到 2 个不同的队列？这也消除了在消息中具有角色属性的需要。在这种情况下，交换类型是不同的。

我的问题

当我们最终在消息中包含类型（在我的示例角色属性中）并强制消费者只听一个队列时，这是一个糟糕的设计吗？还是更好地利用 RabbitMQ 的路由密钥功能，并且永远不要在消息中保留标识属性？

【参考方案1】：

我认为你的例子不好。 Role 不是类型。它是employee 实体的一个属性。如果在签署文件时需要考虑其他属性，例如服务年限。你必须添加不同的队列吗？这些逻辑应该由应用端来完成。而发布者发送的是employee实体，无论它是什么角色，或其他属性。

如果一个订单有两种类型，一种是用户取消订单，另一种是用户完成订单，那么应该有两个队列，使用不同的路由键，例如order.cancel和@ 987654325@.

【讨论】：

也许我的例子不是很好。我想强调和讨论的一点在您的order 示例中更加清楚。因此，根据您对每种类型的示例，我们必须有一个单独的队列，对吗？

是的，这是我的意见。这两种消息的后续操作是不同的。使用一个队列会将不同的操作耦合在一起