似乎我所看到的大多数消息传递系统都具有对优先级消息队列的基本支持（如果有的话） . 例如，AMQP只有specifies至少2个优先级 . RabbitMQ，一个AMQP实现，doesn't support任何优先级 . 在几天内，ActiveMQ将在版本5.4中为10个消息优先级getting support . 10个优先级是JMS spec指定的 .
在非消息传递意义上的单词中的priority queue基于具有无约束的优先级范围的任意字段来对其内容进行排序 . 为什么这样的实现不作为消息传递系统的一部分存在？正如我在 Headers 中所说，优先考虑的是一种固有的非消息传递概念？
我意识到一个答案可能是优先级的概念引入了消息在队列中无限萎缩的可能性，同时处理了更高优先级的消息 . 还有其他原因吗？
5 回答
必须要小心的是，太多的优先级都没有被使用到使用程序变得比通过每个消息更加繁重的程度 .
消息系统的设计和优化是按时间顺序排列的 . 文件系统针对附加文件进行了优化，而不是在开头或中间插入数据 . 类似队列的数据结构通常被优化用于最后追加和从头部移除 . 对于文件系统，这意味着附加到文件（添加）并附加到事务日志（删除），并在消息（删除）后删除它们 .
将优先级引入处理队列有效地将队列转换为具有时间顺序和优先级排序的数据结构 . 基本上，在处理文件存储时，由于必须创建某种索引策略，因此它非常不理想 .
通常，消息队列系统用于确保在不同系统之间传递消息 .
通常，存在某种一次性和一次性保证，并且通常还有一种承诺，即消息将按顺序排列 .
总的来说，然后通知您正在构建和挂钩的系统的设计 .
解耦系统之间的优先级概念通常没有多大意义 .
也就是说，一个常见的解决方法是拥有两个队列，一个是高优先级，一个是后台优先级 . 然后，固有的问题变得清楚，因为当更高优先级的请求进入时，接收系统当然可能无法停止处理低级请求，因此它们通常在该粒度级别上顺序完成 .
BTW ActiveMQ现在通过JMSPriority标头支持5.4.x中的priority messaging .
不是让消息代理在消息到达时重新排序某个缓冲区内的消息，而是通常有更好的技术来实现优先级消耗，例如having a dedicated consumer pool for high priority messages . 然后，无论低优先级消息有多少噪声，高优先级消息总是会得到 .
鉴于消息传递的异步性，如果使用JMSPriority标头之类的东西，它很容易填充缓冲区，网络管道和低优先级消息prefetch queues .
在我看来，这个想法可能更像是“进程优先级”而不是优先级队列中的优先级值 . 当然，这与JMS规范中关于它的一两句话是一致的，并且显然也与AMQP规范一致 .