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

Question

我正在努力更好地理解使用队列设计分布式系统的细微差别，尤其是 RabbitMQ。

假设我有这样的消息

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

和

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

注意角色属性。

发布者将在每个人完成签署文档时发送上述消息。消费者应该根据个人的角色做不同的事情。

设计方法

消息是否应该直接交换（没有路由键）并最终进入1队列？消费者需要收听一个队列，因此它有责任识别哪种类型（基于角色）的参与者签署了文档。
消息是否应该直接交换（与路由键）并最终到达2不同的队列？发布者可以使用 2 个不同的路由键发布消息。 RabitMQ 可以处理路由。消费者将收听 2 个不同的队列。这种方法消除了消息中角色属性的需要。
这是否应该进入主题交换（使用路由密钥）并最终进入 2 不同的队列？这也消除了在消息中具有角色属性的需要。在这种情况下，交换类型不同。

我的问题

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

Answer 1

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

如果一个订单有两种类型，一种是用户取消订单，一种是用户完成订单，那么应该有两个队列，使用不同的routing key，比如order.cancel 和 order.finish.

Is having a type property in a queue message an indication of a bad design in RabbitMQ?