This document describes the deployment architecture of TDMQ for RocketMQ 5.x for you to better understand the architectural principles of TDMQ for RocketMQ.
Deployment Architecture
The system deployment architecture of TDMQ for RocketMQ is as follows:
The TDMQ for RocketMQ 5.x introduces the new gRPC protocol and Proxy components, implementing an architecture featuring separation of computation and storage separation. This significantly changes both the Ops and usage of RocketMQ.
The concepts involved are as follows:
Producer cluster: A client-side application responsible for producing and sending messages.
Consumer cluster: A client-side application responsible for message subscription and consumption.
NameServer cluster: A server-side application responsible for routing address location and Broker heartbeat registration.
Heartbeat registration: The NameServer acts as a registration center. Machines of each role must report its status to the NameServer regularly. If a machine does not report within a certain time window, the NameServer will presume it to be faulty and remove it from the availability list.
Route addressing: Every NameServer stores both the complete routing information of the Broker cluster and the queue information for client queries. Producers and consumers use the NameServer to acquire route information of the entire Broker cluster, which then allows for message delivery and consumption.
Proxy cluster: The new elastic, stateless proxy service splits the Broker responsibilities for the 4.x version, abstracting elements such as client protocol adaptation, permissions management, and consumption management.
Broker cluster: Compared with the 4.x series, the Broker in the 5.x series is more focused on the continuous enhancements of storage capabilities.
Was this page helpful?