background knowledge
JMS is a standard (codenamed JSR 914) developed within the Java Standards Organization (JCP). On June 25, 2001, the Java Message Service released JMS 1.0.2b, and on March 18, 2002, the Java Message Service released 1.1. The
Java Message Service (JMS) application program interface is a message-oriented middleware in the Java platform. A software (MOM) API for asynchronous communication by sending messages between two applications, or in a distributed system.
Point-to-point and publish-subscribe were originally defined by JMS. The main difference or problem between these two modes is whether the messages sent to the queue can be repeatedly consumed (multiple subscriptions)
1. Defined in JMS
The JMS specification currently supports two message models: point to point (queue) and publish/subscribe (publish/subscribe, topic).
Point-to-point:
The message producer produces and sends the message to the queue, and then the message consumer takes it out of the queue and consumes the message. Note here:
after the message is consumed, there is no longer storage in the queue, so it is impossible for the message consumer to consume the message that has been consumed.
Queue supports the existence of multiple consumers, but for a message, only one consumer can consume it.
A publish/subscribe
message producer (publish) publishes a message to a topic, and multiple message consumers (subscription) consume the message at the same time. Unlike the peer-to-peer approach, messages published to a topic are consumed by all subscribers.
2. Analysis and difference between the two
2.1 Peer-to-peer mode
The producer sends a message to the queue, and only one consumer can receive it.
2.2 Publish-Subscribe Model
The message sent by the publisher to the topic, only the subscribers who subscribe to the topic will receive the message.
summary
Queue implements load balancing. A message can only be accepted by one consumer. When no consumer is available, the message will be saved until there is an available consumer. A queue can have many consumers, and the load is realized between them. Balanced,
so Queue implements a reliable load balancing.
Topic implements publish and subscribe. When you publish a message, all services that subscribe to this topic can get the message, so from 1 to N subscribers can get a copy of the message,
only when the message broker receives the message. Only a subscriber with a valid subscription can get a copy of this message.
doubt
In the publish-subscribe mode, can the subscriber load balance consumption be realized? When the publisher has a large amount of messages, it is obvious that the processing power of a single subscriber is insufficient. In fact, in the real scenario, multiple subscriber nodes form a subscription group to load balance the consumption of topic messages, that is, group subscriptions,
so that the subscribers can easily achieve linear expansion of consumption capacity.
3 Comparison of message models of popular message queues
The traditional enterprise message queue ActiveMQ follows the JMS specification and implements the point-to-point and publish-subscribe model, but other popular message queues RabbitMQ and Kafka do not follow the old-fashioned JMS specification. How to achieve consumption load balancing and multiple subscriptions?
3.1 RabbitMQ
RabbitMQ implements the AQMP protocol, which defines the message routing rules and methods. The producer sends messages to different queues through routing rules, and the consumer consumes messages according to the queue name. In addition, RabbitMQ pushes messages to the consumer, and the subscription relationship and consumption status are stored on the server. 
The producer sends a message to the Queue through 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 through routing, and different subscription groups consume the message.
RabbitMQ supports both memory queues and persistent queues. The consumer is a push model. The consumption status and subscription relationship are maintained by the server. Messages are deleted immediately after consumption, and historical messages are not retained. Therefore, when multiple subscriptions are supported, the message will be copied multiple times.
3.2 Kafka
Kafka only supports message persistence. The consumer is a pull model. The client is responsible for maintaining the consumption status and subscription relationship. After the message is consumed, it will not be deleted immediately, and historical messages will be retained. Therefore, when multiple subscriptions are supported, only one copy of the message can be stored.