Introduce a,
Apache RocketMQ is a distributed, queued model of messaging middleware with low latency, high performance and reliability, trillion-scale capacity, and flexible scalability. The core component consists of four parts: Name Servers, Brokers, Producer and Consumer. Each of them can scale horizontally without a single failed node.
- NameServer: is a nearly stateless node that can be clustered and no information is synchronized between nodes
- Broker: The deployment is relatively complex. Brokers are divided into Master and Slave brokers. A Master can correspond to multiple Slavers, but a Slaver can only correspond to one Master. A different BrokerId is defined, with a BrokerId 0 for Master and a non-0 for Slaver. Multiple Master can be deployed. Each Broker establishes long connections to all nodes in the NameServer cluster and periodically registers Topic information to all Nameservers
- Producer: Establishes a long connection with a node (randomly selected) in the NameServer cluster, obtains Topic routing information from NameServer regularly, establishes a long connection with the Master that provides Topic services, and sends heartbeat messages to the Master periodically. Produce is stateless and can be clustered
- Consumer: Establishes a long-term connection with a node (randomly selected) in the NameServer cluster, obtains Topic routing information from NameServer periodically, establishes a long-term connection with the Master and Slaver that provide Topic services, and periodically sends heartbeat messages to the Master and Slaver. Consumers can subscribe to messages from either Master or Slave, depending on the Broker configuration
Ii. MQ installation and deployment
Download 2.1.
To download the latest version after decompression rocketmq.apache.org/release_not directly…
2.2. Modify the configuration
Modify conf/broker.conf to add the following configuration
BrokerIP1: Configure the IP address of the broker Server so that the Name Server can connect
Change runserver.sh and runbroker.sh (optional) Because the rocketMQ default startup parameter takes up a lot of memory, the JAVA_OPT parameter must be changed if the environment does not have this amount of memory
- runserver.sh
JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn125m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m"
Copy the code
- runbroker.sh
JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn125m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m"
Copy the code
2.3. Run Name Server
nohup sh bin/mqnamesrv &
Copy the code
Check run log: tail -f ~ / logs/rocketmqlogs/namesrv log
2.4. Run the Broker
nohup sh bin/mqbroker -n localhost:9876 -c conf/broker.conf &
Copy the code
Through – c parameter specifies the configuration file Check run log: tail – f ~ / logs/rocketmqlogs/broker. The log
2.5. Way to stop service
To stop the RocketMQ service, you are advised to run the kill command instead of the kill command in the production environment
sh bin/mqshutdown broker
sh bin/mqshutdown namesrv
Copy the code
Install a visual management interface
- Download github.com/apache/rock…
- compile
mvn clean package -Dmaven.test.skip=true
Copy the code
- run
Nohup Java jar \ - Drocketmq. Config. NamesrvAddr = 192.168.28.130:9876 \ - Drocketmq config. IsVIPChannel =false\ rocketmq - the console - ng - 1.0.0. Jar &Copy the code
- accesshttp://192.168.28.130:8080/
Four, common exception processing
4.1. MQClientException: No route info of this topic, TopicTest1
4.1.1. Exception Description
When the Producer of the client is running and ready to send messages, an exception is thrown as “No route info of this topic”. The possible causes are as follows:
Broker
Disable automatic creationTopic
And the user did not create a Topic manuallyBroker
Not properly connected toName Server
Producer
Not properly connected toName Server
4.1.2. Solution
- Screen 1:
Broker
Disable automatic creationTopic
Is not created manuallyTopic
- To view broker configuration parameters, run “sh bin/ mqbroker-m” in the RocketMQ directory
- As shown below,
autoCreateTopicEnable=true
There is no problem with the proof
- Screen 2:
Broker
Not properly connected toName Server
By viewing the broker’s logstail -f ~/logs/rocketmqlogs/broker.log
Check for error messages
- Screen 3:
Producer
Not properly connected toName Server
- Check program connection
Name Server
Is the address wrong - If the security group is on a cloud server, check the security group configuration
9876
Port is not developed - See if the firewall is open, if so, set the firewall open
9876
portBash [root@zlt rocketmq-all-4.5.0-bin-release]# firewall-cmd --zone=public --list-ports 8090/ TCP 80/ TCP 8080/ TCP 8080/ TCP [root@zlt rocketmq-all-4.5.0-bin-release]# firewall-cmd --zone=public --add-port=9876/ TCP --permanent success [root@zlt Rocketmq-all-4.5.0-bin-release]# firewall-cmd --reload success [root@zlt rocketmq-all-4.5.0-bin-release]# firewall-cmd --zone=public --list-ports 9876/tcp 8090/tcp 80/tcp 8080/tcp
- Check program connection
4.2. RemotingTooMuchRequestException: sendDefaultImpl call a timeout
4.2.1. Exception Description
- On the client side
Producer
When it runs and is ready to send a message, the throw exception is as follows - Usually because
Name Server
Can’t connectBroker
4.2.2. Solution
Check the RocketMQ-Console cluster TAB for the correct broker address
broker
Install the deployment
- Modify the
broker.conf
Configuration, addbrokerIP1
parameter - Start the
broker
When combined with-c
Parameter specifies the configuration file
4.3. Unable to consume/view messages from the dead-letter queue topic
4.3.1. Exception Description
The default perm value of a dead letter queue is 2
4.3.2. Solution
Change the queue’s PERM to 6 on the console
Modify the perm
Recommended reading
- Log troubleshooting difficulty? Distributed log link tracing to help you
- Zuul integrates Sentinel’s latest gateway flow control components
- Ali Registry Nacos production deployment solution
- Spring Boot custom configuration items implement automatic prompts in the IDE
- How to do Spring Cloud Zuul dynamic routing? Integrating the Nacos implementation is simple
- How can Spring Cloud developers resolve service conflicts and instance hopping?
- How to do distributed transactions in Spring Cloud synchronization scenarios? Try Seata
Scan code attention has surprise!