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:

  1. The decoupling
  2. Peak clipping
  3. asynchronous
  4. Traffic monitoring
  5. Reliable consumption and reliable production of distributed transactions
  6. Indexing, caching, and statically handling data synchronization
  7. Log Monitoring (ELK)
  8. 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:

  1. High coupling
  2. You need to maintain the thread pool yourself
  3. Messages may be lost, so do your own message compensation
  4. Write your own to ensure the reliability of the message
  5. 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:

  1. Support transactions
  2. Spring development, good support for Spring
  3. 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:

  1. Support for distributed transactions
  2. Support message persistence
  3. High performance and high reliability message processing benefits

Kafka is a binary protocol based on TCP/IP. It has the following features:

  1. Simple structure
  2. Fast parsing speed
  3. No transaction support
  4. 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

  1. 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)
  2. Work mode. One producer + one queue + multiple consumers (using the default switch)
    1. Round-robin: Each consumer consumes one message and allocates it evenly. The reply mode is automatic, that is, autoAck = true
    2. 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
  3. Publish and subscribe mode, use fanout switch, send without specifying routekey, meaningless
  4. Routekey = XXX where routekey = XXX To use a direct switch, using fanout makes no sense. Equivalent to publish and subscribe + sort.
  5. Topic pattern topic. * There is one and only one level
  6. RPC
  7. Confirm the model

The roles of rabbitMQ

  1. none
  2. Management: Can only view information about its own nodes
  3. Policymaker: Can create your own
  4. Monitoring: You can watch others
  5. Administrator: All viewable and modifiable

Spring integration the rabbitMQ

Springboot is easy to integrate with RabbitMQ because it is the same company, as follows:

  1. Rely on the spring – the boot – starter – it
  2. Write configuration classes create switches, queues, and their binding relationships.
    1. org.springframework.amqp.core.Queue
    2. org.springframework.amqp.core.FanoutExchange
    3. BindingBuilder.bind(smsQueue()).to(fanoutExchange());
  3. Write a producer
  4. Write about consumers.
    1. Annotations with @rabbitlistenner (Queues = {xxxqueue})
    2. @RabbitHandler

reference

  1. www.rabbitmq.com/getstarted….
  2. This section describes the RabbitMQ working modes