消息优先级在消息队列系统中本质上不重要吗？
我见过的大多数消息系统似乎都对优先级消息队列有基本的支持（如果有的话）。例如，AMQP 仅指定 至少 2 个优先级。 RabbitMQ 是一种 AMQP 实现，不支持任何优先级。几天后，ActiveMQ 将在 5.4 版本中获得对 10 个消息优先级的支持。 10 个优先级由 JMS 指定规格。
非消息传递意义上的优先级队列根据任意字段对其内容进行排序不受限制的优先事项范围。为什么这样的实现不作为消息传递系统的一部分存在？正如我在标题中所问的，优先级本质上是一个非消息概念吗？
我意识到一个答案可能是优先级的概念引入了在处理更高优先级消息时消息无限地滞留在队列中的可能性。还有其他原因吗？
It seems like most of the messaging systems I've looked at have basic, if any, support for priority message queues. For example, the AMQP only specifies a minimum of 2 priorities. RabbitMQ, an AMQP implementation, doesn't support any priorities. ActiveMQ will be getting support for 10 message priorities in version 5.4 in a couple days. 10 priority levels is the specified by the JMS spec.
A priority queue in the non-messaging sense of the word orders its contents based on an arbitrary field with an unconstrained range of priorities. Why does an implementation like this not exist as part of a messaging system? As I asked in the title, is priority an inherently non-messaging concept?
I realize that one answer might be that the concept of priority introduces the possibility of messages infinitely languishing in the queue while higher priority messages are processed. Are there other reasons?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
顺便说一句 ActiveMQ 现在支持优先级5.4.x 中通过 JMSPriority 标头进行消息传递。
通常有更好的技术来实现优先级消耗，而不是让消息代理在某些缓冲区内的消息到达时对其进行重新排序，例如 为高优先级消息拥有专用的消费者池。这样，无论低优先级消息有多少噪音，高优先级消息总是会被通过。
鉴于消息传递的异步性质，很容易填满缓冲区、网络管道和预取队列 如果使用 JMSPriority 标头等，则具有低优先级消息。
BTW ActiveMQ now supports priority messaging in 5.4.x via JMSPriority headers.
Rather than getting the message broker to re-order messages within some buffer as they arrive, there are often better techniques to implement priority consumption, such as having a dedicated consumer pool for high priority messages. Then irrespective of how much noise there is from low priority messages, high priority messages will always get though.
Given the asynchronous nature of messaging its easy to fill up buffers, network pipes and prefetch queues with low priority messages if using things like JMSPriority headers etc.
一般来说，消息队列系统用于确保不同系统之间的消息传递。
通常，有某种一次性的保证，并且通常进一步承诺消息将按顺序发送。
总的来说，这会告诉您正在构建和连接在一起的系统的设计。
解耦系统之间的优先级概念通常没有多大意义。
也就是说，一种常见的解决方法是拥有两个队列，一个高优先级队列和一个后台优先级队列。然而，固有的问题就很清楚了，因为当更高优先级的请求到来时，接收系统当然可能无法停止处理低级请求，因此它们通常在该粒度级别上按顺序完成。
In general, message queue systems are used to ensure delivery of messages between disparate systems.
Usually, there is some sort of once-and-only-once guarantee, and often a further promise that the messages will come in order.
By and large, that then informs the design of the system(s) that you are building and hooking together.
The concepts of priority between decoupled systems often don't make that much sense.
That said, one common workaround is to have two queues, one high priority and one background priority. The inherent problem is then made clear however, because of course the receiving system probably cannot halt processing the low-level request when a higher priority request comes in, so they are generally done sequentially at that level of granularity.
在我看来，这个想法可能更类似于“进程优先级”，而不是优先级队列中的优先级值。当然，这与 JMS 规范中关于它的一两句话是一致的，并且显然也与 AMQP 规范一致。
It seems to me that the idea is probably more akin to "process priority" than the priority values in a priority queue. Certainly that is consistent with the sentence-or-two about it in the JMS spec, and evidently with the AMQP spec as well.
人们必须小心，不要使用太多的优先级，以至于使用该程序变得比浏览每条消息更加繁重。
One has to be careful in that too many priorities aren't used to the point where using the program becomes more burdensome than going through each message.
消息传递系统是按照时间顺序设计和优化的。文件系统针对附加文件进行了优化，而不是在开头或中间插入数据。类似队列的数据结构通常针对在末尾添加和从头部删除进行优化。对于文件系统，这意味着附加到文件（添加）和附加到事务日志（删除），并在消息文件被使用后将其删除（删除）。
将优先级引入处理队列可以有效地将队列转变为同时具有按时间顺序和优先级排序的数据结构。基本上，当涉及到文件存储时，它并不是最优的，因为您必须创建某种索引策略。
Messaging systems are designed and optimized for chronological ordering. File systems are optimized for appending files and not inserting data at the beginning or in the middle. Queue-like data structures are usually optimized for append at the end and removal from the head. For file systems, this means appending to file (adding) and appending to a transaction log (removal), and deleting message files once they are consumed (removal).
Introducing priorities to a processing queue effectively turns the queue into a data structure that has both chronological and priority sorting. Basically, when it comes to working with file storage, it's quite sub-optimal as you have to create some sort of indexing strategy.