RabbitMQ — Starter Kit
What is RabbitMQ?
RabbitMQ is an open-source message broker software written in Erlang which handles clustering and failover very well. It can turn to be your savior to clean up your cluttered and tightly coupled code into well designed, scalable, and reliable application by providing a common platform to send and receive messages.
Why Messaging Framework?
- Common Issues with Monolyth Architecture:
- Tightly Coupled Systems
- Blocking calls
- Communicating with applications running on a different platform and applications developed in different technologies
- Handling communication between applications when one of the applications is down.
- Building Scalable and Reliable systems
- How the above problems can be solved by RabbitMQ — A messaging framework
- Decoupling Tightly Coupled Systems — This can be achieved by using the publish-subscribe feature wherein the sender application sends messages to an exchange and the receiving applications which have subscribed to the queues will receive the messages. It is similar to the sender sending an email that is received by the exchange. The exchange queues the messages to the receiver's mailbox. The receiver can open the mailbox and read the emails at his own pace. This mechanism is also called asynchronous communication.
- Using asynchronous communication to prevent blocking calls — Using the above mechanism blocking calls can be prevented. For example, when you order your food, other people can also order food at the same restaurant at the same time. After ordering your food you need to wait for the food to be prepared after which it is delivered.
- Promoting Interoperability by communicating between cross-platform systems and applications developed in different technologies. — RabbitMQ was basically built on AMQP framework to meet the messaging standards. In addition to this RabbitMQ have client libraries supporting multiple languages which makes it possible for cross-platform and applications developed in different technologies to communicate.
4. Delivering messages to the applications when the Application is up after downtime — Messages can be configured to be persistent so that they are written to disk as soon as they reach the queue. In this scenario, if the receiving application is not up and running the messages can be persisted till the application is up and consumes the messages.
5. Building scalable and reliable systems. — If messages are being delivered to the queue at a faster pace than the consumers can handle them, the queue will just continue to grow. Fortunately, scaling can be done in two ways. You can easily add or remove consumers. You can also allow the broker to scale (add more resources through CPU/disk/memory), to be able to handle more messages in the queue.
API vs Messaging Framework
Most of the above problems can be solved by both APIs and Messaging Framework but you need to pick them up according to the occasions same as you pick your outfit for a party and an official meeting.
APIs can be picked where immediate response is needed i.e. in case of synchronous request-reply.If the client receiving the response is down, the sending service will be blocked while it awaits the reply. Failover and error handling logic should be built into both services.
Message brokers enable asynchronous communications between services so that the sending service need not wait for the receiving service’s reply. This improves fault tolerance and resiliency in the systems in which they’re employed. In addition, the use of message brokers makes it easier to scale systems since a pub/sub messaging pattern can readily support changing numbers of services. Message brokers also keep track of consumers’ states.
Built on Erlang programming language which supports high performance, reliable and durable foundation. Messages can you persisted to disk to the guard from loss in the event that the server is restarted and msg delivery ack can be sent to the sender to ensure message delivery is received and stored.
Works by passing msg by exchanges to be stored in queues. exchange can work with complex routing scenarios by binding exchanges together.
Clustering and High Availability :
Several services can be clustered together on a local network to form a single logical message broker. queues can be moved across multiple servers in a cluster so that in case of server failures msg will not be lost.
Management web interface :
A browser-based user interface that manages users and permissions, exchanges, and queues.
Command-Line interfaces (Rabitmq ctrl/Rabitmq admin):
Commandline tool to carry out administration similar to Management web interface. Rabitmq administration can be carried out using scripts.
The Message Flow in RabbitMQ
- The Producer publishes a message to an exchange. When creating an exchange, the type must be specified.
- The Exchange receives the message and is now responsible for routing the message. The exchange takes different message attributes into account, such as the routing key, depending on the exchange type.
- Bindings must be created from the exchange to queues. In this case, there are two bindings to two different queues from the exchange. The exchange routes the message into the queues depending on message attributes.
- The messages stay in the Queue until they are received by a consumer
- The Consumer receives the message from the subscribed queue.
- When a message is delivered to a consuming application, the consumer notifies the broker, either automatically, or as soon as the application developer chooses to do so. When message Acknowledgements are used, the message broker will only remove the message from the queue when it receives a notification for that message.
- If our user messages are routed by the Routing key, and a message cannot be routed anywhere, it can either be returned to the sender, dropped, or if configured, be placed on a dead letter queue which is monitored.
- Direct: The message is routed to the queues whose binding key exactly matches the routing key of the message.
- Fanout: A fanout exchange routes messages to all of the queues bound to it.
- Topic: The topic exchange does a wildcard match between the routing key and the routing pattern specified in the binding.
- Headers: Headers exchanges use the message header attributes for routing.
Standard queues :
The producer posts directly onto the queue, instead of an exchange. You can post directly to a queue from a client API, under the covers you are posting to the default exchange. For example, when you declare a queue with the name example queue, RabbitMQ broker will bind it to the default exchange using example queue as the rooting key. Therefore a message publishes to the default exchange with the routine key example queue will be routed to that queue. This means that the default exchange makes it seem like it’s possible to deliver messages directly to queues even though that is not actually what is happening behind the scenes.
Worker queues :
The messages from the exchange are distributed between multiple consumers which are also called worker queues. This is commonly used when you want to share the load, between consumers when processing higher volumes of messages.
Publish to subscriber :
The messages are sent from the exchange to all consumers that are bound to the exchange.
Direct Routing :
The message is routed to the queues whose binding key exactly matches the routing key of the message.
- Download and install ERlang http://erlang.org/download/otp_win64_22.3.exe
- Downlaod and install RabbitMQ https://github.com/rabbitmq/rabbitmq-server/releases/download/v3.8.8/rabbitmq-server-3.8.8.exe
- Go to RabbitMQ Server install Directory C:\Program Files\RabbitMQ Server\rabbitmq_server-3.8.3\sbin
- Run command rabbitmq-plugins enable rabbitmq_management
- Open browser and enter http://localhost:15672/ to redirect to RabbitMQ Dashboard
- Also we can Open it with IP Address http://127.0.0.1:15672
- Login page default username and password is guest
- After successfully login you should see RabbitMQ Home page
RabbitMQ Java Spring Boot Code Starter kit