This is the 22nd day of my participation in the Gwen Challenge.More article challenges

Preface:

Message queue is a “first in, first out” data structure, which has the following advantages:

  1. Application decoupling: The more coupled the system, the less fault tolerant it is. Taking e-commerce applications as an example, after users create orders, if they call the inventory system, logistics system and payment system coupled with each other, any subsystem fails or becomes temporarily unavailable due to upgrading or other reasons, the ordering operation will be abnormal and the user experience will be affected.
  2. Peak traffic: An application system may be overwhelmed by a sudden surge in traffic. Message queues can cache a large number of requests and spread them over a long period of time, which greatly improves system stability and user experience.
  3. Data distribution: Message queues allow data to be more widely distributed across multiple systems. The producer of the data doesn’t need to care who uses it, just sends it to the message queue, where the consumer gets it directly.
  4. Asynchronous notification: In order, for example, a user request, need to pay the current orders, inventory, lock hair logistics and a series of operations, simultaneously may take a long time to carry out this a series of process, this time can pass mq asynchronous notification, we don’t need to wait for other services executed only needs to happen an mq notification can return a result set, The rest of the operations are implemented asynchronously, greatly improving the user experience.

Disadvantages:

  1. Reduced system availability: The more external dependencies a system introduces, the less stable the system becomes. Once MQ is down, services are affected. We need to make MQ highly available;
  2. Increased system complexity: The addition of MQ has greatly increased the complexity of systems where synchronous remote calls between systems are now made asynchronously through MQ. How do I ensure that messages are not re-consumed? How to handle message loss? Then ensure that messages are delivered sequentially;
  3. Consistency problem: After processing services, system A sends messages to system B, C, and D using MQ. If system B and C process the messages successfully, system D fails to process the messages. How to ensure consistency of message data processing?

RocketMQ

RocketMQ is a pure Java, distributed, queue model open source messaging middleware, formerly known as MetaQ. It is a queue model messaging middleware developed by Ali based on Kafka features. It was later opened to apache Foundation and became apache’s top open source project. It has the characteristics of high performance, high reliability, high real-time and distributed. The project address

Architecture composition:

It mainly consists of four core components: NameServer, Broker, Producer and Consumer.

  1. NameServer: manages source data, including Topic and routing information.
  2. Producer: A Producer of messages, which is responsible for producing messages. Generally, the business system is responsible for producing messages.
  3. Broker: A role that stores and forwards messages.
  4. Consumer: the message Consumer is responsible for consuming the message, usually the backend system is responsible for asynchronous consumption.

Producer sends messages:

  • Synchronous sending: Synchronous sending means that the sender sends data packets only after receiving the response from the receiver. It is used for important notification messages, such as important notification emails and marketing SMS messages.
  • Asynchronous sending: After sending data, the sender does not wait for the receiver to send back the response and then sends the next data packet. This method is generally used in service scenarios where the link takes a long time and the response time is sensitive, for example, the transcoding service is enabled after a user uploads a video.
  • Unidirectional sending: Unidirectional sending only sends messages without waiting for a response from the server and without triggering a callback function. It is applicable to scenarios that require very short time but do not require high reliability, such as log collection.

Consumer news:

  • Supports PUSH and PULL consumption modes, supports cluster consumption and broadcast messages, and provides a real-time message subscription mechanism.

Pull: Pull consumers actively Pull information from the message server. As long as they Pull messages in batches, the user application will start the consumption process. Therefore, Pull is called active consumption.

Push: The Push Consumer encapsulates the pull, consumption schedule, and other internal maintenance work of the message, leaving the callback interface performed when the message arrives to the user application. So a Push is called a passive consumption type, but from an implementation point of view it still pulls messages from the message server. Different from a Pull, Push first registers a consumption listener and starts consuming messages only after the listener is triggered.

Message domain model

  • Message: Message is the Message to be transmitted.
  • Topic: Topic (Topic) can be thought of as a generic class of messages, which is the first level type of messages.
  • A Tag, which can be thought of as a subtopic, is the second level type of message to provide additional flexibility for the user.
  • Group: A Group that can subscribe to multiple topics. It can be divided into ProducerGroup and ConsumerGroup, which represent producers and consumers of a certain type. Generally speaking, the same service can be used as a Group, and the messages sent and consumed by the same Group are generally the same.

Queue: Message Queue. Topics are divided into one or more subtopics, called Message queues.

Ok! This is the end of today’s article, I hope it can be helpful to you, there are wrong places I hope you can put forward, grow together;

Neat makes for great code, and there’s only so much detail