Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "what is the meaning of Redis message queue". In the operation of practical cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Async

Asynchronous usage scenarios [in line with our real world, which is asynchronous], most of the uses in life are based on asynchronism, such as the request response model for sending and replying to emails.

A service can interact with another service in three ways: Commands, Events, and Queries. A request can be understood to be composed of the main service, the trigger service and the associated service.

Commands . A command is an operation. A request that wants to perform something in another service. Something that changes the state of the system. The command is expected to respond.

Events . The event is both a fact and a trigger. Something happened, expressed as a notice.

Queries . A query is a request, a request to find something. Importantly, the query does not change the state of the system.

Decoupling

The basic meaning of decoupling advocates an idea that is from top to bottom, divide and rule.

Decoupling is the most essential purpose of message queue. Only by separating the delivery and processing of the message, can the decoupling of the message system be realized.

The message-based model is concerned with notification, not processing. Only care about the core process, in the case of multiple tasks, just send a notification.

The classic producer-consumer message model separates production and messages through Broker. Broker is simply a message server, which is responsible for receiving and accessing messages. It can be understood as follows:

In the development of service-oriented project, service-oriented project means that the project is not a single application in nature, but will serve multiple businesses, and the call from upstream to downstream can be done not directly by trigger, but by isolating upstream and downstream through message center.

! [service invocation method .jpg] (upload-images.jianshu.io)

Reliable

001

Reliability simply means that the program numbers the tasks that need to be processed, and each numbered task can be tracked while the task is running. Each task has its own unique mark. For example, the naming rule can be the generation rule of business component name plus timestamp.

Let's take a look at a public case of online information.

Redis storage of the user's last N order records

Several conditions need to be met for this requirement

1 messages need to be stored in order to determine the data structure SortSet

2 globally track each record and encode the data uniquely

[each element in the ordered set of orders is sorted by the number of milliseconds plus the last three digits of the order number as scores. Why not just use milliseconds as a score? Because our order time is only accurate to seconds, if the last three digits of the order number are not added, if there are two or more orders in the same second, the sort score will be the same, resulting in no guarantee of uniqueness when querying the order from the cache according to the score. And the generation rule of our order number can guarantee that the last three digits of the order number in the same second must be different.]

002

When dealing with a task at each stage, a task receipt is needed to indicate the processing status of the task, whether it is a success or failure, or not to refuse to handle it. Let's take the SortSet collection as an example. When the queue processes consumption, it must obtain N items in a certain order from back to back or from back to front. After acquisition, the requested element is processed by the consumer program. The result of processing is the task receipt mentioned above. If consumption fails due to network jitter or downstream of the call chain, the business metadata represented by the selected element will disappear. At this point, it is necessary to determine whether the fetched element needs to be processed separately based on the receipt.

Publish and subscribe under Redis

Using the pubsub function of redis, subscribers subscribe to the channel, and the publisher publishes messages to the channel, which is a message queue.

We can think of publish and subscribe as a real-time communication mode.

001

The redis publish and subscribe usage scenario is obviously to build a real-time messaging system, which depends on the stability of redis server-side long connections. The long link between php and redis is inherently unreliable, and pubsub cannot be used in systems with high reliability requirements. "unreliable" is reflected in the fact that after the subscription is enabled on the server side of the subscription mode, the subscription will expire after a period of time, and you need to turn on the subscription constantly.

For the publish and subscribe function of Redis, a description is found on the Internet.

A producer can correspond to multiple consumers, but it is necessary to ensure that the message publisher and the message subscriber are online at the same time, otherwise, once the message subscriber is forced to disconnect due to various abnormal conditions, the message during its offline period cannot be re-notified (discarded).

For this kind of understanding, the most important thing is how to ensure the long connection status of both hair and hair online in application development.

002

One explanation for "unreliable" is as follows:

Because Redis snooping actually opens a persistent connection operation. Any network fluctuations will be disconnected. It is OK if the network in the server is stable. Or, to put it more accurately, redis long connection is not a preferred option.

Distributed system

The three roles involved in message queues, publishers, Broker, and consumers, can all be deployed and published in the form of clusters. Consumption power can be expanded by increasing the number of machines.

Supplement: according to the reference documentation

Q1: how to avoid message duplication in distributed messaging systems?

The root cause of message duplication is that the network is unreliable. As long as data is exchanged over the network, this problem cannot be avoided. So the way to solve this problem is to bypass it. Then the question becomes: what should be done if the consumer receives two identical messages?

a. The business logic of the consumer side processing messages remains idempotent.

b. Ensure that each message has a unique number and that the successful message processing occurs at the same time as the log of the deduplicated table.

Through idempotency, no matter how many duplicate messages come, the result of processing can be the same. Then use a log table to record the ID of the message that has been successfully processed. If the new message ID is already in the log table, you can no longer process the message and avoid repeated processing of the message.

That's all for "what does Redis message queue mean?" Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.