-
Message BrokerDistributedSystem/Streaming 2020. 5. 3. 14:59
1. Overview
Message Broker is intermediary software that is also called middleware that passes messages between senders and receivers. It may provide additional capabilities like Data transformation, Validation, Queuing, and Routing. And most importantly it provides full decoupling between senders and receivers.
1.1 Motivation
1.1.1 Synchronous Network Communication
One of the properties of direct network communication is that it is inherently synchronous. In this case, we're not referring to the internal threading model or the network API used by the servers but to the fact that through the entire data transaction both the server and the client have to be present and maintain a connection with each other.
And even if the servers are part of different logical clusters or if they communicate with each other through a load balancer both the servers have to maintain the TCP connection to each other or to the load balancer all the way from the first buyer of the HTTP request to the last byte of the HTTP response
1.2 Problematic Scenario
1.2.1 Synchronous Communication Financial Event Pipeline Example
To illustrate the synchronous nature of the direct network communication let's consider a pipeline that handles a financial event. For example, a server can be an online store web application that receives a purchase request from a user. Then to complete the purchase we have to withdraw the money from the user's account so service a would call service B which is the billing service that connects two different credit card companies. And banks after the money have been withdrawn from the user, We need to update the inventory of the product to make sure multiple users would not buy the same item so service B will pass the request to service C which is the inventory service. Finally, we need to request the shipment of the item to the users address so service C will call the shipping service D notice that service a cannot confirm the purchase until service B and sends back a confirmation but service B would not send that confirmation until it gets a response from service C and service C would not send the confirmation until it gets a response from service D. The reason for this chain of dependencies is if for example service response before it gets a confirmation from service B but then service B crashes and doesn't build a user the user would get a false confirmation about an order he will never receive. Alternatively, if service B sends back confirmation after billing the user but before a response from service C arrives and service C fails the user will end up paying for a product he will also never receive. So inevitably we are holding the user for a long time until we can safely send the confirmation and the longer we keep those connections the more chances are that one of them will actually break.
1.2.2 Broadcasting Event to Many Services
One of our servers wants to broadcast an event to many different services that are interested in receiving it. The problem with this scenario is that the more servers want to receive that event the more direct connections the publisher server will have to open so this approach just would not scale.
1.2.3 Traffic Peaks and Valleys
When the traffic to our system has drastic peaks during which our system just cannot handle the incoming events all at once. For example, if we have a social media distributed system where sometimes there is a live event during which millions of users comment all at once during that time our analytics back-end service may not keep up with the rate of events and would simply crush. So having some sort of queue where we could store all those events in order temporarily would definitely help to solve the problem.
2. Difference between Load Balancer and Message Broker
2.1 Load Balancer
Load-balancing proxies make themselves unnoticeable to clients and servers and creates an illusion of servers talking to each other directly
2.2 Message Broker
Message broker enforces its own Network protocol data formats and APIs. The best part about message brokers is they decouple the system to the extent that a receiver does not have to be present.
2.2.1 Load Balancing
2.2.2 Queuing
3. Capabilities
3.1 Asynchronous system
3.2 Publish/Subscribe
3.2.1 Sending
Using the publish/subscribe paradigm, a sender can publish a message to multiple servers by sending a single message to the message broker and the message broker will take care of broadcasting it to all the intended subscribers without the sender even knowing who they are
3.2.2 Receiving
A receiver may subscribe to a single topic or queue and receive messages from many publishers without knowing anything about them
3.3 Push/Pull
3.3.1 Without Message Broker
As long as the server is listening on the port it doesn't have any control and when and how frequently to receive the messages
3.3.2 With Message Broker
When we're using a message broker the sender pushes the messages to the message broker and the receiver pulls those messages. Whenever it chooses to that poling approach gives a lot more control to the receivers over the rate of messages consumption
4. Scalability
To avoid the Message Broker from being a single point of failure or a bottleneck, Message Brokers need to be scalable and fault-tolerant. Message Brokers are distributed systems by themselves which makes them harder to design and configure. The latency, when using a message broker, in most cases, is higher than when using direct communication.
5. Use Cases
- Distributed Queue: Message delivery from a single producer to a single consumer
- Publish/Subscribe: Publishing of a message from a single publisher to a group of subscribed consumers
6. Reference