JMS主题与队列 - 意图

Question

I am trying to understand the use case of using Queue.

My understanding: Queue means one-to-one. The only use case(if not rare, very few) would be: Message is intended for only one consume.

But even in those cases, I may want to use Topic (just to be future safe). The only extra caution would be to make subscriptions durable. Or, in special situations, I would use bridging / dispatcher mechanism.

Given above, I would always (or in most cases) want to publish to a topic. Subscriber can be either durable topic(s) or dispatched queue(s).

Please let me know what I am missing here or I am missing the original intent?

Answer 1

The design requirements on when to use queues are simple if you think in terms of real-world examples:

• Submit online order (exactly-once processing to avoid charging credit card twice)
• Private peer-to-peer chat (exactly one receiver for each message)
• Parallel task distribution (distribute tasks amongst many workers in a networked system)

...and examples for when to use topics...

• News broadcast to multiple subscribers; notification service, stock ticker, etc.
• Email client (unique durable subscriber; you still get emails when you're disconnected)

You said...

But even in those cases, I may want to use Topic (just to be future safe). The only extra case I would have to do is to make (each) subscription durable. Or, I special situations, I would use bridging / dispatcher mechanism.

You're over-engineering the design. It's true, you can achieve exactly-once processing using a topic and durable subscriber, but you'd be limited to a single durable subscriber; the moment you start another subscriber for that topic, you'll get duplicate processing for the same message, not to mention, a single durable subscriber is hardly a solution that scales; it would be a bottleneck in your system for sure. With a queue, you can deploy 1000 receivers on 100 nodes for the same queue, and you'd still get exactly-once processing for a single message.

You said...

Give above, I would always (or in most cases) want to publish to a topic. Subscriber can be either durable topic(s) or dispatched queue(s).

Using a dispatched queue with a topic subscriber is sort of redundant. You basically get asynchronous dispatching when using queues, so why not just use a queue?...no reason to put a topic in front of it.

Answer 2

You are probably missing that both queues and topics can have multiple subscribers. A queue will deliver the message to one of potentially many subscribers, while a topic will deliver the message to all subscribers.

If you in your case is sure that there is only one subscriber, then a queue subscriber and a durable topic subscriber will behave similarly. I would rather look at such a scenario as a "special case".

Answer 3

Queues and Topics in JMS represent two different models - point to point and publish/subscribe. Topics will keep a message until all clients receive them, all subscribers handling them. Queues will wait for the first consumer to pull the message, and consider it read at that point.