How RocketMQ's NameSrv Works

🌐 中文

English

This article aims to introduce the working principles of RocketMQ’s NameSrv.

What is NameSrv

NameSrv is a crucial component of RocketMQ. It acts like a bulletin board, responsible for managing and maintaining RocketMQ’s metadata information, including Broker registration and routing information maintenance. NameSrv provides a centralized service for storing and managing RocketMQ’s configuration information and metadata, enabling other components to retrieve this information through NameSrv. Therefore, it must be started before the Broker.

NameSrv and Broker

When a Broker starts, it reports its information to NameSrv every 30 seconds. NameSrv scans the recorded broker information every 10 seconds and removes brokers that have not reported for over 120 seconds.
The reported information includes:

1. topicQueueTable It describes the queueData information for each topic, including the Broker’s name and the corresponding number of queues, etc.
2. brokerAddrTable It describes the information for each brokerName, including the Broker’s name and the corresponding IP address, etc.
3. clusterAddrTable Brokers have the concept of clusters. This map records the association between clusters and their corresponding Brokers, allowing all Brokers under a cluster to be found by the cluster name.
4. brokerLiveTable This map records the live status of each Broker. By using the BrokerAddr, you can find the corresponding Broker’s latest reported update time, version number, read/write channels, etc.
5. filterServerTable This map records the address of the filter service for each Broker. By using the BrokerAddr, you can find the corresponding filter service address.

The Role of NameSrv for Producers and Consumers

The information reported by the Broker to NameSrv is intended for use by Producers and Consumers.
Producers retrieve routing information about Topics from NameSrv every 30 seconds, establish long connections with the corresponding Brokers, and cache the routing information in memory (the cache is lost upon restart). Subsequently, they directly send messages to the corresponding Topic.
Consumers need to connect to NameSrv upon startup, establish a long connection with it, and retrieve the mapping relationships between topics and brokers from it. They also establish long connections with the relevant Brokers, subscribe to the corresponding Topics, and receive pushed messages when they are sent.

How to Handle NameSrv Failures

To handle NameSrv failures, multiple NameSrvs need to be deployed to form a NameSrv cluster.
Because the NameSrv implemented by Rocket is very lightweight, NameSrvs within the cluster do not exchange any information. Therefore, Brokers need to report routing information to every NameSrv in the cluster, ensuring each NameSrv stores complete routing information.
Since the data across all NameSrvs is identical, Producers and Consumers only need to randomly select one NameSrv in the cluster to establish a long connection and obtain the full routing information.