我看过的大多数消息系统似乎都对优先级消息队列有基本的（如果有的话）支持。例如，AMQP 仅“指定”至少 2 个优先级。 RabbitMQ 是一种 AMQP 实现，不支持任何优先级。几天后，ActiveMQ 将在 5.4 版本中“获得对 10 个消息优先级的支持”。 JMS 规范指定了 10 个优先级。 非消息传递意义上的优先级队列基于具有不受限制的优先级范围的任意字段来排序其内容。为什么这样的实现不作为消息传递系统的一部分存在？正如我在标题中所问的，优先级本质上是一个非消息概念吗？
我意识到一个答案可能是优先级的概念引入了在处理更高优先级消息时消息无限地滞留在队列中的可能性。还有其他原因吗？顺便说一句，ActiveMQ
现在通过 JMSPriority 标头支持 5.4.x 中的通常有更好的技术来实现优先级消费，而不是让消息代理在某些缓冲区内的消息到达时对其进行重新排序，例如为高优先级消息提供专用的消费者池。这样，无论低优先级消息有多少噪音，高优先级消息总是会被通过。
考虑到消息传递的异步性质，如果使用 JMSPriority 标头等内容，则很容易用低优先级消息填充缓冲区、网络管道和预取队列。
解耦系统之间的优先级概念通常没有多大意义。
也就是说，一种常见的解决方法是有两个队列，一个高优先级和一个后台优先级。然而，固有的问题就很清楚了，因为当“更高优先级”请求进入时，接收系统当然可能无法停止处理低级别请求，因此它们通常在该粒度级别按顺序完成。
在我看来，这个想法可能更类似于“进程优先级”，而不是优先级队列中的优先级值。当然，这与 JMS 规范中关于它的一两句话是一致的，显然也与 AMQP 规范一致。
必须小心，不要使用太多优先级，以至于使用该程序变得比浏览每条消息更繁重。
消息系统是按照时间顺序设计和优化的。文件系统针对附加文件进行了优化，而不是在开头或中间插入数据。类似队列的数据结构通常针对在末尾添加和从头部删除进行优化。对于文件系统，这意味着附加到文件（添加）和附加到事务日志（删除），并在消息文件被使用后将其删除（删除）。