This series is a summary note of the book "RabbitMQ in Action: Efficient Deployment of Distributed Message Queues".
Through the introduction of the first two articles, I learned about the main elements and interaction process of message communication, and how to run and manage RabbitMQ. This article will understand the benefits of "message-oriented communication" from the perspective of development mode, as well as in various scenarios. best practices below.
Through the introduction, you will learn:
- The benefits of message-oriented communication
- Forget model
- Implementing RPC with RabbitMQ
The benefits of message-oriented communication
Mainly from the aspects of asynchronous state thinking, processing capability scalability, and integration complexity, the benefits of message-oriented communication are explained.
Asynchronous state thinking
When integrating message communication into an application, the development model will change from a synchronous model to an asynchronous model, RabbitMQ provides a different approach that allows us to send requests in one place and process them in another, so that the synchronous program can continue to execute other logic.
To give a simple example to illustrate, pay the credit card through Alipay:
- The user fills in the credit card number, issuing bank, cardholder name, repayment amount, and submits the repayment application;
- Alipay will immediately prompt the user that the application has been submitted and how many hours will the repayment be completed;
- After the repayment is completed, a message will be sent to the user to remind whether the repayment is successful;
If it is a synchronous request, the user needs to wait for several hours to view the result, and other operations cannot be performed during the waiting process, which is very unreasonable.
Asynchronous thinking is to separate the request and processing, and use RabbitMQ in the middle of the two tightly coupled parts of the application. After the request is parsed, a message that the business can understand is sent to RabbitMQ, and it is returned to the user. The real processing is handled asynchronously by another service. .
Extensibility
With the expansion of the business, the requirements for service processing capacity are getting higher and higher, RabbitMQ can easily increase the processing capacity.
Because RabbitMQ can distribute requests evenly among processing servers, there is no need for a load balancer.
Zero cost API
To call each other between systems, a set of APIs needs to be agreed. Generally speaking, it takes a little time to write a large piece of code to convert incoming HTTP requests into function calls in the application.
If AMQP is used to connect various parts of the application, there is no need to define additional APIs, just use message communication. Also, AMQP is language-agnostic, with native language bindings for dozens of languages.
Forget model
When considering the types of problems that messaging can solve, the main area where messaging is applicable is the "send and forget" processing model. The concern is that the task will complete, but not in real-time, create a task, send it to the exchange, and return to work without even notifying the user that the task is complete.
Two types of tasks that match this pattern:
- Batch processing: For work or transformation of large data sets, multiple tasks operate on independent parts of the data set;
- Notification: A description of the event sent, which can be a log of messages, or notification to another program or administrator;
The examples introduced in the book are relatively simple, so they are not listed here, mainly to determine the type and routingkey of the switch according to different scenarios. You can refer to the example of "collecting logs" introduced in the previous article for understanding.
Implementing RPC with RabbitMQ
There are many ways to implement remote procedure call RPC, such as REST API, SOAP, Thrift, etc. These traditional RPC implementation methods have something in common: the client and the server are closely connected, and they have to wait for the return result. Also consider these questions:
- When there are multiple service nodes, how does the client discover the corresponding server;
- If the RPC server to which the client is connected crashes, the client needs additional logic to reconnect;
When implemented through the MQ server, it simply publishes the message, routes the message to the appropriate place, and loads the message through multiple RPC servers. When the server processing the message crashes, the RPC message is resent to another tower.
Now the question is, what if the reply is returned to the client?
RabbitMQ uses messages to send back responses. There is a field in the AMQP message header called reply_to. The producer of the message can use this field to determine the queue name, and listen to the queue to wait for a response. The message receiver can check the reply_to field and create a response containing the response. The content of the new message, with the queue name as the routing key.
Regarding the queue name of reply_to, if the producer declares a queue without a name, RabbitMQ will automatically generate a unique queue name, and specify the exclusive parameter when declaring it to ensure that only the producer who created the queue can read the messages on the queue.
In this way, all the RPC client has to do is declare a temporary, exclusive, anonymous queue and include the queue name in the reply_to header of the RPC message, so that the server knows where to send the reply message.
Many scenarios use the "send and forget" model, which does not require a response from the handler. If a response is required, RabbitMQ's RPC model can be used.
The next article will cover RabbitMQ clustering and high availability and their setup.
Welcome to scan the QR code below and follow my personal WeChat public account~
