Message Queuing difference between midpoint to point and publication subscription

Background knowledge

JMS is a standard developed within the Java Standardization Organization (JCP) (codenamed JSR 914). June 25, 2001 , Java Messaging Service released JMS 1.0.2b,2002 March 18 Java messaging Service Release 1.1.
The Java Messaging Service (Java message SERVICE,JMS) application interface is an API for message-oriented middleware (MOM) in the Java platform for sending messages between two applications, or distributed systems, for asynchronous communication.
Point-to-point and publish subscriptions are initially defined by JMS. The main difference between the two modes is whether the message sent to the queue can be repeated (multi-subscription)

Defined in 1.JMS

The JMS specification currently supports two message models: Point-to-point, queue, and publish/subscribe (PUBLISH/SUBSCRIBE,TOPIC).
Point-to-point:
Message producer production messages are sent to the queue , and then the message consumer takes out the queue and consumes the message. Here to note:
After the message is consumed, there is no more storage in the queue, so the message consumer cannot consume the message that has been consumed.
Queue support exists for multiple consumers, but for a message, only one consumer can consume it.
Publish/Subscribe
The message producer (release) publishes the message to topic and has multiple message consumers (subscriptions) consuming the message. Unlike point-to-point methods, messages posted to topic are consumed by all subscribers .

2. Analyze and differentiate between the two 2.1 point-to-point modes

The producer sends a message to the queue and only one consumer can receive it.

2.2 Publish Subscription Mode

The publisher sends a message to topic, and only subscribers who have subscribed to topic receive the message.

Summary

Queue is load balanced, a message can only be accepted by a consumer, when no consumer is available, the message will be saved until there is an available consumer, a queue can have a lot of consumers, they achieve load balancing,
So the queue achieves a reliable load balancer.
Topic implements the publish and subscribe, when you publish a message, all subscriptions to this topic service can get this message, so from 1 to N subscribers can get a copy of the message,
A copy of this message is only available to subscribers who have a valid subscription when the message agent receives the message.

Questions

In the Publish subscription mode, can subscribers load-balance consumption be realized? When the volume of a publisher's message is large, it is clear that the processing power of a single subscriber is insufficient. In fact, the real scene is that multiple subscriber nodes form a subscription group load-balanced consumption topic messages are grouped subscriptions,
This makes it easy for subscribers to expand their consumption capabilities linearly.

3 Popular Message Queuing model comparisons

Traditional enterprise Message Queuing ACTIVEMQ follows the JMS specification, implements a point-to-point and publish-subscribe model, but other popular Message Queuing RABBITMQ, Kafka do not follow the old JMS specification, how to achieve consumption load balancing, multi-subscription?

3.1 RabbitMQ

RABBITMQ implements the AQMP protocol, and the AQMP protocol defines the message routing rules and methods. The production side sends messages to different queues through routing rules, consuming messages based on the queue name. Also RABBITMQ is to push messages to the consumer, and the subscription relationship and consumption status are saved on the server side.

The production side sends a message to the queue via routing, and only one consumer can consume it.

When RABBITMQ needs to support multiple subscriptions, the message sent by the publisher is written to multiple queues at the same time by routing, and the message is consumed by different subscription groups.
RABBITMQ supports both memory queue and persistent queue, consumer is push model, consumption status and subscription relationship is maintained by service side, the message is deleted immediately after consumption, and historical message is not preserved. So when multiple subscriptions are supported, multiple copies of the message are available.

3.2 Kafka

Kafka only supports message persistence, consumer is pull model, consumption status and subscription relationship is maintained by the client side, the message will not be deleted immediately after consumption, will retain the historical message. Therefore, when multiple subscriptions are supported, the message will only be stored in one copy.

http://blog.csdn.net/lizhitao/article/details/47723105

Message Queuing difference between midpoint to point and publish subscription (GO)