What is a message queue
Messages are data passed between different applications. The message here can be very simple, such as containing only a string, or it can be very complex, containing multiple nested objects. Message Queue (Message Queue) is simply a way of communication between applications. The message is returned immediately after being sent, and the message system guarantees the reliable transmission of the message. The message producer only needs to send the message to the MQ. , You don’t need to care about message consumption. Similarly, message consumers only need to pull messages from MQ regardless of who produced the messages. Through such a "mutually unknown object existence" model, the producer of the message and the consumption of the message Decoupled.
When to consider using message queues
From the above, we can know that message queue is an asynchronous cooperation mechanism between applications, so when do we need to use MQ? Taking a common order system as an example, the business logic after the user clicks "Place Order" may include: deducting inventory, generating corresponding order data, and sending SMS notifications. In the initial stage of project and business development, these logics may be executed together. As the number of orders for business development increases, the performance of system services needs to be improved. At this time, some operations that do not need to take effect immediately can be separated and executed asynchronously. Such as sending SMS notifications. In this scenario, MQ can be used. After the main order process (such as deducting inventory, generating order data, etc.) is completed, a message is sent to MQ to quickly complete the main process, and then another thread will pull the MQ message and execute it. The corresponding business logic. The example here mainly uses message queues to decouple.
Features of RabbitMQ
RabbitMQ is an open source implementation of AMQP developed by Relang language. AMQP (Advanced Message Queue: Advanced Message Queue Protocol) is an open standard for application layer protocols. It is designed for message-oriented middleware. Clients and message middleware based on this protocol can transmit messages and are not affected by products and development languages. And other conditions. RabbitMQ originally originated from a messaging system, used to store and forward messages in a distributed system. It has the following characteristics:
Reliability RabbitMQ uses some mechanisms to ensure reliability, such as persistence, transmission confirmation mechanism (ack), and release confirmation.
Flexible routing strategy Before the message enters the queue, the message is routed through Exchange. For typical routing functions, RabbitMQ has provided some built-in Exchange implementations. For complex routing functions, multiple Exchanges can be tied together, and their own Exchanges can also be implemented through a plug-in mechanism.
Message cluster Multiple RabbitMQ servers can form a cluster to form a logical Broker.
High-availability queues can be mirrored on the clusters in the cluster, so that the queues are still available when some nodes have problems.
Multiple protocols RabbitMQ supports multiple message queue protocols, such as STOMP, MQTT, etc.
The multilingual client RabbitMQ almost supports many commonly used languages, such as Java, .NET, etc.
The management interface RabbitMQ provides an easy-to-use user interface that enables users to monitor and manage many aspects of the message broker.
RabbitMQ installation (mac) and running
1. Installation Because RabbitMQ relies on the Erlang language, you need to install the Erlang environment before installing RabbitMQ. However, because it is a Mac environment, you can use HomeBrew to install. Update brew before installing:
brew update
Then install RabbitMQ, the Erlang it depends on will be installed automatically during the installation process.
2. The startup and operation of RabbitMQ is very simple. After finding its installation directory (the default directory installed with Homwbrew is: /usr/local/Cellar/rabbitmq), enter the sbin directory of the directory, and you can see that there are 6 with rabbitmq For the executable file at the beginning, simply execute rabbitmq-server.
If the startup is normal, you can see the log information of the startup process and the final completed with 6 plugins, which also means that 6 plugins are loaded by default during startup.
At this point, visit http://localhost:15672 through a browser to see its management interface (the default user name and password are both guest), and you can add users on the admin tab page. The management interface is as follows:
PS: The above method is not to start in the background. If you want to start RabbitMQ as a background daemon, you can add the -detached parameter when starting.
3. Query server status. There is an executable file rabbitmqctl under sbin of the installation directory, which provides almost one-stop solutions for RabbitMQ management, and it can provide most of the operation and maintenance commands. The parameter status can be used to query the status information of RabbitMQ server.
Basic concepts in RabbitMQ
1. Message model Almost all MQ abstractions are the same process: Consumers subscribe to a certain queue, producers produce messages, then publish them to the queue, and finally send the messages to the consumers who listen to the queue. As shown below:
2. Basic concepts The above abstract overview of the message queue, specifically RabbitMQ has some unique concepts, RabbitMQ is an open source implementation of the AMQP protocol, and most of its internal concepts are some concepts of the AMQP protocol.
3. Message routing in AMQP There are some differences between the message routing process in AMQP and the familiar JMS that Java developers are familiar with. The roles of Exchange and Binding have been added to AMQP. The producer sends the message to the Exchange, the message finally arrives in the queue and is received by the consumer, and the Binding determines which queue the exchange's message should be sent to.
4. Exchange type Exchange has slightly different distribution strategies according to different types when distributing messages. There are currently four types: direct, fanout, topic, headers. The headers match the AMQP message header instead of the routing key. In addition, the headers switch and the direct switch are exactly the same, but the performance is much worse, and it is almost unused at present, so just look at the other three types.
4.1, direct type
If the routing key in the message is consistent with the binding key in the Binding, the exchange sends the message to the corresponding queue. The routing key exactly matches the queue name. If a queue is bound to the switch and requires the routing key to be "dog", only the message marked with the routing key "dog" will be forwarded, and "dog.puppy" will not be forwarded, nor will it be forwarded. dog.guard" and so on. It is an exact match, unicast mode.
4.2, fanout type
Every message sent to the fanout type exchange will be sent to all bound queues. The fanout exchange does not process routing keys, but simply binds the queue to the exchange, and every message sent to the exchange will be forwarded to all queues bound to the exchange. Much like subnet broadcasting, each host in the subnet gets a copy of the message. The fanout type is the fastest to forward messages.
3. Topic type
The topic switch assigns the routing key attributes of the message through pattern matching, and matches the routing key with a pattern. At this time, the queue needs to be bound to a pattern. It divides the routing key and the bound string into words. These words Separate with dots. It also recognizes two wildcard characters: the symbol "#" and the symbol "". The # symbol matches 0 or more words, and the symbol matches no more or less than one word, which is also the most used type in actual projects.
to sum up
This article mainly talks about the installation of RabbitMQ and the introduction of basic concepts. Since it is developed based on the Erlang language, it may not be very friendly for some Java developers who want to understand the underlying implementation details and troubleshoot more complex problems.