RABBITMQ Introduction (i)

Rabbitmq. Install RABBITMQ and common commands under Windows

RABBITMQ is an enterprise messaging system that is complete and can be taken on a standard based on the AMQP protocol. It follows the Mozilla Public License Open Source protocol, an industrial-grade Message Queuing server implemented with Erlang, and RABBITMQ is built on the Erlang OTP platform.

1. Installing Erlang
   Before installing RABBITMQ, you need to install Erlang and install address http://www.erlang.org/download.html.
   Configure environment variables after successful installationERLANG_HOME=D:\Program Files\erl10.1
2. Installing RABBITMQ
   Official website http://www.rabbitmq.com/download.html
   It is important to note that the default installation RABBITMQ listening port is 5672

3. Configuration

   1. Activating RABBITMQ ' s Management Plugin

      With the RABBITMQ management plug-in, you can better visualize the status of your RABBITMQ server instances.
      CMD Input command"D:\Program Files\RabbitMQ Server\rabbitmq_server-3.7.8\sbin\rabbitmq-plugins.bat" enable rabbitmq_management
      
      After the plug-in installation is successful, the service needs to be restartednet stop RabbitMQ && net start RabbitMQ
      
      Error may occur: "System error 5 has occurred" and is not system administrator rights
      Problem Resolution: Use the Administrator to open cmd to execute the command again
      

   2. Create user, password, bind role

      Use the rabbitmqctl console command to create a user, password, bind permission, etc.
      RABBITMQ user management includes adding users, deleting users, viewing the list of users, and modifying user passwords.

• View existing users and user rolesrabbitmqctl.bat list_users
  
• Add a userrabbitmqctl.bat add_user username password
  
  Query users and roles will find [Administrator], this is the role of RABBITMQ, RABBITMQ can be divided into 5 categories: Super Administrator, monitor, policy-makers, general administrators and others.
  • Super Admin (Administrator)
    • Login to the admin console (with management plugin enabled) to view all the information and to operate on the user, policy
  • Monitor (monitoring)
    • Login to the admin console (with management plugin enabled), while you can view information about the RABBITMQ node (number of processes, memory usage, disk usage, etc.)
  • Policy makers (policymaker)
    • You can log in to the management console (with management plugin enabled) and manage the policy.
  • General Manager (Management)
    • You can only log in to the administration console (with management plugin enabled), you cannot see the node information, and you cannot manage the policy.
  • Other
    • Unable to login to the management console, usually the average consumer and producer.
• Add a role to a userrabbitmqctl.bat set_user_tags [user] [role]
  
  In addition to adding administrator roles to users, you can add roles such as monitoring,policymaker,management, custom names, and so on.
  In addition, you can set multiple roles for a userrabbitmqctl.bat set_user_tags [user] [role1] [role2]...
  
• Modify User Passwordrabbitmqctl.bat change_password [user] [password]
• Delete Userrabbitmqctl.bat delete_user [user]
  1. VirtualHost and Rights Management
• VirtualHost
  • Like MySQL has the concept of a database and can specify user permissions for operations such as libraries and tables. RABBITMQ also has similar permissions to manage. In RABBITMQ you can virtualhost a virtual messaging server, each virtualhost is a relatively independent RABBITMQ server, each of which is isolated from each other. Exchange, queue, and message are not interoperable.
  • VirtualHost cannot be created through AMQP in RABBITMQ, can be created by command rabbitmqctl add_vhost [vhostname] , or it can be created through the administration console. Such as
• Rights Management
  • It is divided into three parts: Create users , assign Roles , set permissions (This section mainly explains setting permissions )
  • Configure Permissionsset_permissions [-p <vhostpath>] <user> <conf> <write> <read>

Through the http://localhost:15672 login Management console, you can view information, monitoring, policy and other operations.

Second, the preliminary understanding of RABBITMQ

2. How messages are delivered (Producer message delivery is switch-oriented)
   The RABBITMQ is a switch-oriented delivery message. The switch may be bound to a number of queues, so how does the switch deliver the message to these queues?
   Benefits of Switch-oriented design:
   • With the design idea of the switch on the data link layer. In addition to the hierarchy, the link utilization can also be increased from the points.
   • From the code level: if there is no switch, you must maintain at least one very large routing table and then correctly post messages from the routing table. With the switch, the routing table is split into multiple switches.
   • Highly decoupled, different switches can have different routing rules
     In RABBITMQ, the switch has a 4 delivery method, which is the enumeration class Builtinexchangetype 4 enumeration variables:
   • DIRECT: All messages are Route_keyfirst and then posted to the queue bound to Route_key(if(msg.routekey.equals(queue.routekey)))
   • fanout: In this mode, the route_keyof the message is not checked at all and delivered directly to all the queues owned by the switch
   • TOPIC:
   • HEADERS:
4. Consumers how to consume messages (consumer messages are Message Queuing-oriented, which is a bit different from the generator)
   channel.basicConsume(QUEUE_AUTODELETE, true, consumer);Consumer is an instance of the consumer class.
6. Whether consumer transmission is reliable
   Reliable.
8. Declaration period of a message
   Once the consumer responds and the identity message is consumed, the message is recycled
10. Queue Declaration Period
    channel.queueDeclare(QUEUE_NAME, false, false, true, null);
    The second parameter is set to NULL, persisting the message to disk the fourth parameter is set to True to delete the queue without a message and no connection

MQ's related name

2. ConnectionFactory, Connection, Channel
   All three are the most basic objects in the API provided by RABBITMQ.
   Connection is the socket link for RABBITMQ, which encapsulates some of the logic associated with the socket protocol.
   ConnectionFactory is a manufacturing facility for connection.
   Channel is the most important interface we have with RABBITMQ, and most of our business operations are done in the channel interface, including defining queue, defining exchange, binding queue and exchange, publishing messages, and so on.
4. Queue
   A queue is an internal object of RABBITMQ that is used to store messages.
   Messages in RABBITMQ can only be stored in a queue, producers produce messages and are eventually delivered to the queue, and consumers can get messages from the queue and consume them.
   Multiple consumers can subscribe to a queue, when messages in the queue are evenly distributed to multiple consumers and processed, not every consumer receives all the messages and processes them.
6. Message Acknowledgment
   In real-world applications, consumers may receive messages from the queue, but they do not complete the performance outage (or other surprises), which can lead to the loss of messages. To prevent this from happening, we can ask the consumer to send a receipt after consuming the message to RABBITMQ,RABBITMQ to receive the message receipt (msg acknowledgment) before removing the message from RABBITMQ If RABBITMQ does not receive a receipt and detects that the consumer's RABBITMQ connection is broken, RABBITMQ will send the message to other consumers (if multiple consumers exist) for processing. There is no concept of timeout here, and a consumer processing the message longer will not cause the message to be sent to other consumers unless its RABBITMQ connection is broken.
   There is another problem here, if our developers forget to send receipts to RABBITMQ after they have processed the business logic, this will result in more and more messages piling up in serious bug-queue, and consumers will repeat consuming the messages and repeating the business logic when they restart.
   In addition, pub message is not ack-free.
8. Message Durability
   If we want to not lose the message even when the RABBITMQ service is restarted, we can set the queue and message to be persisted (durable), which guarantees that our RABBITMQ messages will not be lost in most cases. But still can not solve the small probability of the loss of events (such as the RABBITMQ server has received the message of the producer, but not enough time to persist the message when the RABBITMQ server is powered off), if we need to manage this small probability event, then we have to use the transaction.
10. Prefetch Count
    We said earlier that if more than one consumer subscribes to a message in the same queue, the message in the queue is split to multiple consumers. At this point, if the processing time of each message is different, it may cause some consumers to be busy, while others quickly finish the work at hand and always idle. We can set Prefetchcount to limit the number of messages each queue sends to each consumer, such as our settings prefetchCount=1 , and queue sends a message to each consumer each time the queue sends a message to the consumer after the message is processed.
12. Exchange
    We learned that producers are delivering messages to the queue, which in fact never happens in RABBITMQ. The reality is that the producer sends the message to Exchange (the exchanger), and the Exchange routes the message to one or more queue (or discards).

• What logic does exchange follow to route messages to a queue? will be introduced in 8, the binding
• Exchange in RABBITMQ is made up of four types, different types have different routing policies, which are described in 10, exchange types

1. Routing Key
   When a producer sends a message to exchange, a routing key is typically specified to specify the routing rules for the message, and the routing key needs to be used in conjunction with Exchange type and binding key to finally take effect.
   In cases where Exchange Type and Binding key are fixed (usually these are fixed in normal use), our producers can specify routing key to determine where the message flows when sending messages to exchange. The RABBITMQ has a length limit of 255bytes for routing key.
2. Binding
   Exchange is associated with the queue through binding in RABBITMQ so that RABBITMQ knows how to properly route messages to the specified queue.
3. Binding Key

• At the same time as binding (binding) Exchange and queue, a binding key is typically specified;
• When a consumer sends a message to exchange, a routing key is typically specified;
• When the binding key matches the routing key, the message is routed to the corresponding queue.
  These bindings allow the same binding key to be used when binding multiple queues to the same exchange. The binding key does not take effect in all cases, it relies on exchange type, for example, exchange of type fanout ignores the binding key, but instead routes the message to all the queue bound to that exchange.

1. Exchange Types
   RABBITMQ Common Exchange type has fanout,direct,topic,headers four (the AMQP specification also mentions two Exchange types, system and custom, which are not described here)

• Fanout
  • The fanout type of Exchange routing rule is simple, and it routes all messages sent to that Exchange to all the queues that are bound to him.
• Direct
  • Direct will route the message to the queue whose binding key matches the routing key exactly.
• Topic
  • The previous Exchange routing rules for the direct type are exactly the same as the binding key and routing key, but this strict matching method does not meet the actual business requirements in many cases. The topic type of exchange extends on matching rules, similar to direct, and also routes messages to a queue with a binding key that matches routing key, but there are some differences in the matching rules, which contract: routing Key is a . string separated by a period number (we will be the period number ".") Each separated section of a separate string is called a word). such as stock.usd.nyse , nyse.vmw ,quick.orange.rabbit
  • Binding key is the same as routing key . , which is a string separated by a period.
  • There can be two special characters in the binding key that are * # used to make a fuzzy match, which * is used to match a word that # matches multiple words (which can be 0).
• Headers
  • The headers type of exchange does not rely on the matching rules of routing key and the binding key to route messages, but rather matches the headers attributes in the message content sent.
  • Specifies a set of key-value pairs when a queue is bound to exchange, and when a message is sent to Exchange, RABBITMQ takes the headers of the message (which is also a key-value pair). Compares whether the key-value pair exactly matches the key-value pair specified by the queue with Exchange bindings, or if the exact match message is routed to the queue, otherwise it is not routed to the queue.

1. Rpc
   MQ itself is asynchronous-based message processing, and all the Producers (P) in the previous example send messages to RABBITMQ without knowing that the consumer (C) processing succeeds or fails (even if there is no consumer to handle the message).
   However, in the actual application scenario, we will probably need some synchronous processing and need to wait for the server to finish processing my message before proceeding to the next step. This is equivalent to the RPC (remote Procedure call, which is called remotely). RPC is also supported in RABBITMQ.

• The mechanism for implementing RPC in RABBITMQ:
  • When a client sends a request (message), the properties of the message (Messageproperties, 14 properties defined in the AMQP protocol, which are sent along with the message) set two values ReplyTo (a queue name, Used to tell the server to send a message to the queue after processing is complete, and Correlationald (the identification number of this request, the server will need to return this property after processing is completed, the client is based on this ID to know which request was executed successfully or failed to execute).
  • The server receives the message and processes
  • After the server finishes processing the message, a reply message is generated to the ReplyTo specified to the queue with the Correlationald property
  • After the client has subscribed to the queue specified by ReplyTo and receives a reply message from the server, it analyzes which request is executed based on the Correlationald property, and then performs subsequent business processing based on the execution result.

Reference

Https://www.cnblogs.com/ericli-ericli/p/5902270.html
71191851?utm_source=itdadao&utm_medium=referral

RABBITMQ Introduction (i)