18
RABBITMQ EXAMPLE
A message broker can act as a middleman for various services. A broker can be used to
reduce loads and delivery times by web application servers. A task that would generally
take a lot of time to process can be delegated to a third party whose only job is to
perform them.
This chapter is a case study of a web application, a PDF generator. The application
allows users to upload information to a website. The website handles the information
and generates a PDF, which is then emailed back to the user. The whole processing in
this example takes several seconds to perform.
When the user has entered user information into the web interface, the web applica-
tion puts a “PDF processing” job into a message, including information about the job
such as name and email. The message is then placed onto a queue dened in RabbitMQ
using an exchange process. The underlying architecture of a message queue is simple
- client applications called producers create messages and deliver them to the broker.
The broker is, essentially, the message queue. Other applications, known as consumers,
connect to the queue and subscribe to messages from the broker, processing those
messages according to their function. The software interacting with the broker can
be a producer, a consumer, or both. Messages placed in the queue are stored until the
consumer retrieves them.
If the PDF processing application crashes, or if many PDF requests are coming at the
same time, messages would continue to pile up in the queue until the consumer starts
again. It would then process all the messages, one by one.
Figure 2 - A sketch of the RabbitMQ workow.
WHY AND WHEN TO USE RABBITMQ
Message queuing allows web servers to respond to requests in their own time instead
of being forced to perform resource-heavy procedures immediately. Message queuing
is also useful for distributing a message to multiple recipients for consumption or when
balancing the load between workers.
The consumer application removes a message from the queue and processes the PDF
at the same time as the producer pushes new task messages to the queue. The consumer
can be on an entirely different server than the publisher or they can be located on
the same server, it makes no difference. Requests can be created in one programming
language and handled in another programming language, as the two applications only
communicate through the messages they are sending to each other. The two services
have what is known as ‘low coupling’ between the sender and the receiver.
我的内容管理
展开
