Analysis of RocketMQ Routing Registration Mechanism, Its Defects, and the Impact of Network Partitions

A fan asked about RocketMQ's routing registration mechanism, prompting the author to provide a detailed analysis.

RocketMQ's routing registration works as follows: every 30 seconds a Broker sends a heartbeat containing topic routing information (queue counts, permissions, etc.) to the NameServer, which updates the Topic routing in a HashMap and records the latest timestamp. The NameServer cleans up dead Brokers every 10 seconds, considering a Broker down if the current time minus the last heartbeat exceeds 120 seconds. Producers pull routing information every 30 seconds, so they do not instantly perceive newly added or removed Brokers. When a Broker‑NameServer connection breaks, the Broker’s routing is removed from the NameServer immediately, but clients must actively refresh to notice the change.

This simple and efficient implementation has two obvious drawbacks: producers and consumers cannot promptly detect Broker failures or “zombie” states, and NameServers do not communicate with each other, leading to temporary routing inconsistencies.

In the case of a network partition, the temporary inconsistency can become prolonged. If two network segments cannot communicate, the routing information stored in each NameServer diverges. Producers that connect to only one NameServer will send all messages to the brokers known to that NameServer, causing uneven load distribution. Consumers that connect to a single NameServer will only see queues from the brokers reachable through that NameServer, resulting in partitioned consumption where some messages remain unconsumed.

These issues stem from an architectural trade‑off: RocketMQ’s NameServer prioritises simplicity and high performance, accepting brief inconsistencies as non‑catastrophic. In contrast, a system like Zookeeper that enforces strong consistency could become unavailable under partition, violating high‑availability goals.

For further reading, see the recommended articles on Redis source code, cache‑database consistency, multi‑active geo‑replication, Redis transactions, distributed locks, and MVCC principles.