消息队列系统中的消息优先级本质上是不重要的吗？

Question

似乎我所看到的大多数消息传递系统都支持优先级消息队列（如果有的话）。例如，AMQP仅specifies至少2个优先级。 RabbitMQ，一个AMQP实现，doesn't support任何优先级。 ActiveMQ将在几天内在版本5.4中针对10个消息优先级getting support JMS spec。 10个优先级是priority queue指定的。

该词的非消息传递意义上的{{3}}基于具有无约束的优先级范围的任意字段来对其内容进行排序。为什么这样的实现不作为消息传递系统的一部分存在？正如我在标题中提到的那样，优先级是一种固有的非消息传递概念吗？

我意识到一个答案可能是优先级的概念引入了消息在队列中无限萎缩的可能性，同时处理了更高优先级的消息。还有其他原因吗？

Answer 1

BTW ActiveMQ现在通过JMSPriority标头支持5.4.x中的priority messaging。

不是让消息代理在到达时在某个缓冲区内重新排序消息，而是通常有更好的技术来实现优先级消耗，例如having a dedicated consumer pool for high priority messages。然后，无论低优先级消息有多少噪声，高优先级消息总是会得到。

鉴于消息的异步性质，如果使用JMSPriority标头之类的东西，它很容易填充缓冲区，网络管道和prefetch queues低优先级消息。

Answer 2

通常，消息队列系统用于确保在不同系统之间传递消息。

通常，有一种一次性和一次性的保证，并且通常会进一步承诺消息将按顺序排列。

总的来说，它会告知您正在构建和挂钩的系统的设计。

解耦系统之间的优先级概念通常没有多大意义。

也就是说，一个常见的解决方法是拥有两个队列，一个是高优先级，一个是后台优先级。然而，固有的问题很明显，因为当更高优先级请求进入时，接收系统当然可能无法停止处理低级请求，因此它们通常在该粒度级别上顺序完成

Answer 3

在我看来，这个想法可能更像是“进程优先级”而不是优先级队列中的优先级值。当然这与JMS规范中关于它的一两句话是一致的，并且显然也与AMQP规范一致。

Answer 4

必须要小心的是，太多的优先级都没有被使用到使用程序变得比通过每条消息更加繁重的程度。

Answer 5

消息系统的设计和优化是按时间顺序排列的。文件系统针对附加文件进行了优化，而不是在开头或中间插入数据。类似队列的数据结构通常被优化用于最后追加和从头部移除。对于文件系统，这意味着附加到文件（添加）并附加到事务日志（删除），并在消息（删除）后删除消息文件。

将优先级引入处理队列有效地将队列转换为具有时间顺序和优先级排序的数据结构。基本上，在处理文件存储时，由于必须创建某种索引策略，因此它非常不理想。