RabbitMQ basic theory
RabbitMQ belongs to message middleware, which is based on queuing and message passing technology, and provides synchronous or asynchronous and reliable message transmission support software system for application systems in network environment
1. Synchronous and asynchronous communication
There are two ways of communication between microservices: synchronous and asynchronous:
Synchronous communication: Just like you call your sister or handsome guy, you need to respond in real time, and you can only call another person after the call is over.
Asynchronous communication: Just like chatting on WeChat, you don’t need to reply immediately, you can chat with multiple younger sisters or handsome guys at the same time.
Both methods have their own advantages and disadvantages. You can get an immediate response when you make a call, but you can't talk to multiple people at the same time. Sending messages can send and receive messages with multiple people at the same time, but there is often a delay in response.
1. Synchronous communication
Feign remote call is a synchronous method. Although the call can get the result in real time, there are the following problems:
Summarize:
Advantages of synchronous calls:
- Time-sensitive, results can be obtained immediately
Problems with synchronous calls:
- High coupling
- Degraded performance and throughput
- has additional resource consumption
- There is cascading failure problem
2. Asynchronous communication
Asynchronous calls can avoid the above problems:
Let's take the purchase of goods as an example. After the user pays, he needs to call the order service to complete the order status modification, call the logistics service, allocate the corresponding inventory from the warehouse and prepare for delivery.
In the event mode, the payment service is the event publisher (publisher). After the payment is completed, it only needs to publish a successful payment event (event), with the order id in the event.
The order service and logistics service are event subscribers (Consumer), who subscribe to the event of successful payment, and complete their own business after listening to the event.
In order to remove the coupling between event publishers and subscribers, the two do not communicate directly, but have a middleman (Broker). Publishers publish events to Broker, regardless of who subscribes to events. Subscribers subscribe to events from Broker and don't care who sends the message.
Broker is something like a data bus. All services to receive data and send data are sent to this bus. This bus is like a protocol, making communication between services standard and controllable.
benefit:
-
Throughput improvement: there is no need to wait for subscribers to complete processing, and the response is faster
-
Fault isolation: the service is not called directly, and there is no cascading failure problem
-
There is no blocking between calls, which will not cause invalid resource occupation
-
The degree of coupling is extremely low, each service can be flexibly plugged and replaced
-
Traffic peak clipping: No matter how much the traffic of the published event fluctuates, it will be received by Broker, and subscribers can process events at their own speed
shortcoming:
- The structure is complicated, and the business has no obvious process line, which is difficult to manage
- Need to rely on Broker's reliability, security, and performance
2. Technical comparison
MQ, Chinese is Message Queue (MessageQueue), literally it is a queue for storing messages. That is, the Broker in the event-driven architecture.
More common MQ implementations:
- ActiveMQ
- RabbitMQ
- RocketMQ
- Kafka
Comparison of several common MQs:
Pursuit of availability: Kafka, RocketMQ, RabbitMQ
Pursuit of reliability: RabbitMQ, RocketMQ
Pursuit of throughput: RocketMQ, Kafka
Pursue low message latency: RabbitMQ, Kafka