This is the third day of my participation in Gwen Challenge
Why do we use message queues?
Message queues.
When it comes to why MQ is used, we have to talk about MQ usage scenarios. Its main usage scenarios are as follows:
- The decoupling
- Peak clipping
- asynchronous
- Traffic monitoring
- Reliable consumption and reliable production of distributed transactions
- Indexing, caching, and statically handling data synchronization
- Log Monitoring (ELK)
- Place orders, distribute orders, grab tickets
Its main function is to parallelize serial operations. For this purpose, we can of course write parallel programs ourselves, but there are several disadvantages to using asynchronous thread pools:
- High coupling
- You need to maintain the thread pool yourself
- Messages may be lost, so do your own message compensation
- Write your own to ensure the reliability of the message
- If the server cannot support it, write your own high availability
This allows for the creation of a message queue.
Advice, if you just was a start-up company recommended or use monomer architecture, the more a cache middleware can, do not blindly pursue new or so-called high performance, and the pursuit of must be behind the driver and the project of the driver of the business, because once the pursuit means that your learning cost, the personnel structure of the company and the server costs, The cost of maintenance and operation and maintenance will increase, so you need to choose and consider carefully.
Why RabbitMQ? (Technical selection)
The reasons for choosing RabbitMQ are as follows:
- Support transactions
- Spring development, good support for Spring
- Open source
Compare several MQ commonly used in the market:
ActiveMQ | RabbitMQ | Kafka | RocketMQ | |
---|---|---|---|---|
Release subscription | support | support | support | support |
Polling distribution | support | support | support | / |
Fair distribution | / | support | support | / |
resend | support | support | / | support |
Message pull | / | support | support | support |
The comparison shows that:
- Both support persistence
- Both support publish and subscribe
- Overall, RabbitMQ supports the most distribution policies. Supports polling and retransmission
Brief introduction to messaging middleware protocols
Common message-oriented middleware protocols are:
- OpenWire
- AMQP (Advanced Message Queuing Protocol)
- MQTT
- Kafka
- OpenMessage
Various protocols are generally improved based on TCP and standardized through protocols to meet their own needs.
Why doesn’t messaging middleware use HTTP?
- For maximum performance, HTTP request headers and response headers are complex.
- Most of the time HTTP is short-connected and unreliable.
RabbitMQ uses AMQP and has the following features:
- Support for distributed transactions
- Support message persistence
- High performance and high reliability message processing benefits
Kafka is a binary protocol based on TCP/IP. It has the following features:
- Simple structure
- Fast parsing speed
- No transaction support
- There is persistent design
MQTT: Internet of Things system support
The pattern of message queues
There are 7 officially defined patterns, and 5 are mainly used
- Simple mode. One producer + one queue + one consumer (using the default exchange, no exchange is specified so the routingKey will write the queue name when sending messages)
- Work mode. One producer + one queue + multiple consumers (using the default switch)
- Round-robin: Each consumer consumes one message and allocates it evenly. The reply mode is automatic, that is, autoAck = true
- Work mode – Fair distribution: quick processing, more processing, distribution according to work. Be sure to change to manual reply, which is the consumer’s autoAck = false, and answer manually. Qos indicator: Indicates the number of queues to be fetched each time
- Publish and subscribe mode, use fanout switch, send without specifying routekey, meaningless
- Routekey = XXX where routekey = XXX To use a direct switch, using fanout makes no sense. Equivalent to publish and subscribe + sort.
- Topic pattern topic. * There is one and only one level
- RPC
- Confirm the model
The roles of rabbitMQ
- none
- Management: Can only view information about its own nodes
- Policymaker: Can create your own
- Monitoring: You can watch others
- Administrator: All viewable and modifiable
Spring integration the rabbitMQ
Springboot is easy to integrate with RabbitMQ because it is the same company, as follows:
- Rely on the spring – the boot – starter – it
- Write configuration classes create switches, queues, and their binding relationships.
- org.springframework.amqp.core.Queue
- org.springframework.amqp.core.FanoutExchange
- BindingBuilder.bind(smsQueue()).to(fanoutExchange());
- Write a producer
- Write about consumers.
- Annotations with @rabbitlistenner (Queues = {xxxqueue})
- @RabbitHandler
reference
- www.rabbitmq.com/getstarted….
- This section describes the RabbitMQ working modes