This series is the summary note for RabbitMQ In Action: Deploying Distributed Message Queues efficiently.

Having seen the main elements of messaging and interaction, and how to run and manage RabbitMQ, this article will understand the benefits of message-oriented communication from a development pattern perspective, as well as best practices in various scenarios.

Through introduction, you will learn:

  • Benefits of message-oriented communication
  • Post and forget the model
  • Implement RPC with RabbitMQ

Benefits of message-oriented communication

The benefits of message-oriented communication are explained from the aspects of asynchronous state thinking, processing capability expansion and integration complexity.

Asynchronous state thinking

The development model changes from synchronous to asynchronous when message communication is integrated into the application, and RabbitMQ provides a different way to send a request in one place and process it in another, so that the synchronizer can continue to execute other logic.

Here’s a simple example of paying a credit card via Alipay:

  • The user fills in the credit card number, issuing bank, cardholder’s name and repayment amount, and submits repayment application;
  • Alipay will prompt the user immediately, the application has been submitted, how many hours to complete the repayment;
  • After the repayment is completed, a message will be pushed to the user to remind whether the repayment is successful.

If the request is synchronous, the user has to wait for several hours to see the result, and no other action can be performed during the waiting time, which is quite unreasonable.

The asynchronous mindset is to separate the request from the processing, using RabbitMQ between the two tightly coupled parts of the application, parsing the request, sending a message that the business understands to RabbitMQ, and sending it back to the user, with the real processing being handled asynchronously by another service.

scalability

RabbitMQ can easily add more processing power to the service as it expands.

Because RabbitMQ can distribute requests evenly across processing servers, there is no need for a load balancer.

Zero cost API

Systems call each other, need to agree on a set of apis, and typically, it takes a little time to write a large piece of code to translate incoming HTTP requests into function calls in the application.

If you use AMQP to connect parts of your application, you don’t need to define additional apis, just use message communication. In addition, AMQP is language independent, with local language bindings for dozens of languages.

Post and forget the model

When considering the types of problems that messaging can solve, the main area where messaging is applicable is the “post and forget” processing pattern. The concern is that the task will be completed, but not in real time. Create a task, send it to the switch, and then go back to work without even notifying the user that the task is complete.

Two types of tasks match this pattern:

  • Batch processing: For the work or transformation of a large data set, multiple tasks operate on separate parts of the data set;
  • Notification: A description of a sent event, either as a log of a message or as a notification to another program or administrator;

The examples introduced in the book are relatively simple and will not be listed here. The main point is to determine the type and routingkey of the switch according to different scenarios. You can refer to the example of “Collecting logs” in the previous article for understanding.

Implement RPC with RabbitMQ

There are many ways to implement remote procedure call RPC, such as REST apis, SOAP, Thrift, and so on. These traditional RPC implementations have something in common: the client and server are closely linked and wait for the result to return. Consider these other 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 via an MQ server, messages are simply published, routed to appropriate locations, load-balanced across multiple RPC servers, and relayed to another when one server handling the message crashes.

Now the question is, what if I send the reply back to the client?

RabbitMQ uses messages to send replies back. The AMQP header has a field called reply_TO that the producer of the message uses to determine the queue name and listen to the queue for a reply. The receiver can examine the Reply_TO field and create a new message containing the reply. And use the queue name as the routing key.

With respect to reply_to queue names, if the producer declares an unnamed queue, RabbitMQ will automatically generate a unique queue name and specify exclusive to ensure that only the producer who created the queue can read the messages on the queue.

All RPC clients need to do, then, 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 “fire and forget” model and do not require a handler response. If a response is required, RabbitMQ’s RPC model can be used.

The next article will cover RabbitMQ clustering and high availability and their Settings.

Please scan the qr code below and follow my personal wechat official account ~