1. How is RocketMQ clustered to host high concurrent access?
- NameServer is clustered on three machines. NameServer is designed to be deployed in peer-to-peer mode, but each machine runs independently of the other machines. Each NameServer actually has complete cluster routing information, including all Broker node information, our data messages. So as long as any NameServer survives, the MQ system is safe from failure.
2. Dledger based Broker master-slave architecture deployment,Dledger technology requires at least one Master with two slaves, so that there are three Broke to form a Group, that is, run as a Group. If the Master goes down, he can elect a new Master from the remaining two slaves
2. How to implement a distributed storage architecture if RocketMQ is going to store massive amounts of messages?
RocketMQ processes deployed on each machine are commonly called brokers, and each Broker receives different messages and stores these messages in its own local disk files
3,High availability: What if the Broker goes down?
RocketMQ’s solution is the Broker master-slave architecture and multi-copy strategy.
4. Data routing: How do I know which Broker to visit?
NameServer is deployed independently on several machines, and all brokers register themselves with NameServer to manage information for all brokers in the cluster
5. When sending a message, it is necessary to send it to the Broker on N machines
6,What is the data model for RocketMQ, and when we send messages, do we send them to something, a queue or something?
7,Does RocketMQ write directly to disk after receiving the data? Will that performance be poor
8. For example, is the Broker actively pushing messages to consumers? Or do consumers pull their own messages from Broke?
NameServer can be clustered
10,Which NameServer does the Broker register its information with?
- Each Broker startup must be registered with all NameserVers
11,How does the system get Broker information from NameServer?
12,How does NameServer sense if the Broker is down?
- The Broker sends a heartbeat to all Nameservers every 30 seconds to tell each NameServer that it is alive
13. NameServer then runs a task every 10s to check the last heartbeat of each Broker. If a Broker has not sent a heartbeat for more than 120s, it is considered dead
14,How does the system sense that the Broker is down?
NameServer did not send a heartbeat message to NameServer for 120s. NameServer knows that there are only nine brokers now, but other systems do not know that there are only nine brokers at this time. They thought there were 10 brokers. It is possible that a system will send a message to the failed Broker, at which point the message will never be sent successfully
- First, you can consider sending messages to other brokers instead of that Broker.
- Suppose you have to send a message to that Broker, and it hangs up. His Slave machine is a backup and can continue to be used. Would you consider waiting a while to communicate with his Slave?
Kafka’s routing center
- Kafka’s routing center is actually a very complex, chaotic existence. This is done by ZooKeeper and a Broker acting as Controller.
The NameServer cluster is down. Is RocketMQ still up and running
17,How does the Master Broker synchronize messages to the Slave Broker?
- The Slave Broker sends requests to the Master Broker to pull
18. What if the Master Broker fails?
Prior to RocketMQ version 4.5, data was synchronized using a Slave Broker to ensure that data was not lost, but if the Master failed, the Slave could not automatically switch to the Master.
19. RocketMQ high availability automatic switching based on Dledger
Dledger is a mechanism implemented based on Raft protocol
Dledger technology and Raft protocol algorithm can be used to elect a Slave Broker as the new Master Broker in multiple copies, that is, in multiple slaves. The new Master Broker can then be served externally