To access a message queue for the new application, you need to create related resources, including Vhost, User, Exchange, and Queue.
Create a Vhost
(1) Log in to the console of message queue rabbitMQ;
(2) Go to the management page of the corresponding instance;
(3) Click Cluster Management on the left tab, and then enter the Vhost on the main interface;
(4) Click New and enter the virtual host name to add Vhost.
Note the following requirements when setting the Vhost name:
Vhost name can only contain letters, numbers, dashes (-) and underscores (_).
The length of the Vhost name is limited to 1~64 characters, and if the length exceeds 64 characters, it will be automatically intercepted.
After the Vhost is successfully created, the Vhost name cannot be modified.
(1) Log in to the console of message queue rabbitMQ;
(2) Go to the management page of the corresponding instance;
(3) Click Cluster Management, and then enter the User Interface on the main interface;
(4) After successful creation, configure Vhost permissions for the user and select the target Vhost.
(5) After successful creation, configure Vhost permissions for the user, select the target Vhost, then enter the host details, click the permissions tab page, and click Add Permissions.
(6) After successful creation, configure Vhost permissions for the user, select the target Vhost, then enter the host details, click the permissions tab page, and click Add Permissions.
Tips: The permission configuration rule is a regular expression. For example, * indicates all permissions
For example, '^(amq\.gen.*|amq\.default)$' can match the server-generated and default exchange, and '^$' does not match any resources.
Create an Exchange
When creating a Vhost, 5 default Exchanges will be created. If you need to create additional Exchanges, you can enter the Exchange tab of the instance list to create a new one.
Parameter | Description |
Virtual Host | Select the virtual host to which the exchange is created |
Name | The name of the exchange. Fields starting with amq. are reserved fields and cannot be used. For example: amq.test. |
Type | Exchange type. Value: |
direct: This type of routing rule will route the message to the Queue whose Binding key exactly matches the Routing key. | |
topic: This type is similar to direct. Topic Exchange routing rules are not as strict as Direct Exchange and support fuzzy matching and multi-criteria matching, i.e., this type of Exchange uses Routing Key pattern matching and string comparison to route messages to the bound Queue. | |
fanout: This type of routing rule is very simple, it will route all messages sent to the Exchange to all queues bound to it, which is equivalent to the broadcast function. | |
headers: This type is similar to direct. Headers Exchange uses the Headers attribute instead of Routing Key for routing matching. When binding Headers Exchange and Queue, set the key-value pair of the binding attribute. When sending a message to Headers Exchange, set the Headers attribute key-value pair of the message, and route the message to the bound Queue by comparing the message Headers attribute key-value pair with the binding attribute key-value pair. | |
x-delayed-message: By declaring this type of Exchange, you can customize the Header attribute x-delay of the message to specify the time period for delayed message delivery, in milliseconds. Messages will be delivered to the corresponding queue based on the routing rules after the time period specified in x-delay. The routing rules depend on the Exchange routing type specified in x-delayed-type. | |
x-delayed-type | When the Exchange type is x-delayed-message, you need to configure this parameter to specify the routing type of Exchange. |
Persistence or Not | Whether the exchange is persisted to disk |
Whether to delete automatically | If so, the exchange will be deleted when at least one queue or exchange is bound to it and then all queues or exchanges have been unbound. |
Built-in or Not | If so, the client cannot publish directly to this exchange. It can only be used in conjunction with other exchanges. |
Other Parameters | Alternate exchange: The backup exchange is to implement messages that are not routed to the queue. When declaring the exchange, add the attribute alternate-exchange and declare an alternate exchange. Generally, it is declared as fanout type, so that messages received by the exchange that are not routed to the queue will be sent to the queue bound to the alternate exchange. |
Create a Queue
You can declare it in code and the queue will be automatically created. Or enter the console and create a new instance in the queue tab of the instance list.
Parameter | Description |
Virtual Host | Select the virtual host to which the queue created |
Name | The name of the queue. Fields starting with amq. are reserved fields and cannot be used. For example: amq.test. |
Storage Node | Queue data storage node |
Persistence or Not | Whether the queue metadata is persisted to disk |
Whether to delete automatically | Whether the Queue is automatically deleted after the last Consumer unsubscribes. |
Other Parameters | Message TTL Message expiration time: number type (unit: ms) Auto expire Queue expiration time (automatically deleted after the queue is expired: number type (unit: ms)) Max length Maximum number of messages that can be stored in a queue: number type (unit: number) Max length bytes Maximum number of messages that can be stored in a queue: number type (unit: byte) Overflow behaviour Message receiving policy after the maximum limit of the queue is exceeded: drop-head or reject-publish drop-head: Delete the header message, which is generally the earliest message sent, to ensure queue availability reject-publish: Refuse to receive new messages to ensure that messages are not lost Dead letter exchange Name of Dead Letter Exchange Dead letter routing key Dead Letter Routing Key Maximum priority Maximum queue priority: To enable the priority of a message, you must set the priority of the queue that contains the message Lazy mode Queue lazy modes: default and lazy default: default value and ordinary queue lazy: indicates a lazy queue. Messages are saved to disks as much as possible, resulting in a large number I/O operations, and little memory consumption (it is recommended for scenarios with a large accumulation of persistent messages) Master Locator Queue save location: client-local, min-masters and random client-local: nodes used for connection during queue creation min-masters: Node with the smallest number of active nodes in the cluster random: Randomly specify a node by the RabbitMQ server |