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