RABBITMQ Learn 3----run and manage RABBITMQ

1. Service for Management

Erlang is born to communicate with the application without needing to know if the other person exists on the same machine.

Erlang node: each instance of an Erlang virtual machine. Multiple Erlang applications can run on top of the same node. Local communication can be made between nodes (regardless of whether they are running on the same server). An example of this is that an application running on Node A can invoke the application's method on Node B, just as if it were called a local function. If the application crashes for some reason, the Erlang node will automatically attempt to restart the application.

1.1 Start Node

Run the./rabbitmq-server in the RABBITMQ installation directory. You can also start the RABBITMQ node by increasing the-detached parameter, running in the background as a daemon:./rabbitmq-server-detached.

1.2 Stop node

Run under the RABBITMQ installation directory:./rabbitmqctl stop, Rabbitmqctl communicates with the local node and directs its clean shutdown. You can also specify to close different nodes, including remote nodes. You only need to pass in the-n [email protected][hostname] option. The entire RABBITMQ node, including Erlang, is closed.

Stop RABBITMQ only need to run:./rabbitmactl Stop_app.

Configuration file for 1.3RabbitMQ

[   {mnesia,[{dump_log_write_threshold,1000}]},   {rabbit,[{vm_memory_high_watermark,0.4}]}   ]

The RABBITMQ configuration file is an array that contains a nested hash table table. With an external configuration array, each Erlang application will have its own hash table to configure the options.

Note: The metadata for each queue, exchanger, and binding in RABBITMQ is saved to Mnesia. Mnesia is a non-SQL database built into Erlang. Mnesia ensures its integrity by writing RABBITMQ metadata to an append-only log file. The log content is then periodically dumped into a real Mnesia database file.

2. Request permission

You can set different levels of permissions (read, write, and configure) for users who are connected to RABBITMQ. The benefit of RABBITMQ permissions is that a single user can authorize across multiple vhost.

2.1 Managing Users

In RABBITMQ, the user is the basic unit of access control. For one or more vhost, they can be given different levels of access and authenticate users with a standard username/password. Adding, deleting, and listing users is easy. These operations are done through RABBITMQCTL.

The command to create the user is as follows:

./rabbitmqctl add_user Username Password

The command to delete a user is as follows:

./rabbitmqctl Delete_user Username

When a user is deleted, any access control entries that reference that user are automatically deleted from the Rabbit permissions database.

The commands for viewing all users are as follows:

./rabbitmqctl List_users

The command to modify the password for an existing user is as follows:

./rabbitmqctl Change_password Username NewPassword

RABBITMQ Learn 3----run and manage RABBITMQ