I. Rabbit works

  • Program decoupling, such as when large amounts of data need to be written repeatedly over time
  • As RabbitMQ’s load increases, it has a load-balancing effect because its messages are looped out to consumers

Second, forget the model after the hair

One of the main models applicable in the field of message communication is the post and forget model. We only care that these tasks will be completed, not that they will be completed in real time.


1. Send a warning


2, batch processing: upload pictures will have more than one business, such as logging, increase integral and so on can be through the famous exchange: will match the message to all attached in this exchange queue to broadcast your successful upload task to trigger the task behind.

Third, the cluster

RabbitMQ always logs the following four types of internal metadata

  • Queue metadata: Queue names and their properties (are they persistent, are they automatically deleted?)
  • Switch metadata: Switch name, type, and properties (persistent)
  • Binding metadata: A simple table showing how to route a message to a queue
  • Vhost metadata: Provides clear space and security attributes for queues, switches, and bindings within the vhost

1. Queues in the cluster

The queue of a single node Rabbit in the cluster holds its own queue information and queue binding relationships. The other nodes have only the metadata of the queue (i.e. the name and properties of the queue example) and do not hold the queue contents or binding relationships. Cause synchronization replication overhead is too large ^_^.

Note: Problem 1: When Rabbit restarts its queue’s binding relationships are also destroyed, and the message is destroyed

Solution: Set queue persistence at the beginning.

2. Switches in the cluster

The switch exists only logically, and the routing function is equivalent to a query table that records the queue information. After the message of the channel is obtained, it will be matched and bound in different ways in this table.


Note: problem 1, before the routing binding happened message loss how to do?

Solution: 1. Use AMQP transactions. 2. Return confirmation message to record the information that has not been confirmed when the connection was interrupted. These two methods are used to confirm that the message cannot be routed to the destination queue. When fully replicated in the cluster, the route is guaranteed to be successful and not a single piece of information is lost.

3. Is it a memory node or a disk node

Each RabbitMQ node, whether it is a single-node system or cluster, is either a memory node or a disk node.

  • The memory node stores all queues, switches, bindings, users, permissions, and vhost metadata only in memory
  • Disk stanzas store metadata on disk

Single-node systems only allow disk-type nodes, otherwise all configuration information will be lost each time you reboot. It is also possible to optionally configure some nodes in the cluster as memory nodes for better performance of message flow


Note: The reason for having a memory node in the cluster is that all cluster nodes need to synchronize their metadata when a switch, queue, or binding is declared in the cluster. For disk that means a lot of disk operations, for memory that means changing write memory. It is common for at least one node in the cluster to be written to disk and for the other nodes to fail and metadata to be recovered.